[Slackbuilds-users] requirements in README files
dragonwisard at gmail.com
Tue Jul 10 13:07:42 UTC 2012
I truly respect all of this reverence for "the Slackware way", however that
really feels like an excuse. A few years ago it wasn't "the Slackware way"
to run on 64-bit x86, but now it is. It also wasn't "the Slackware way" to
use xz compression, but now it is. Before that it wasn't "the Slackware
way" to use an automated tool to download and install/update packages, but
then slackpkg was added. And so on. What is or isn't "the Slackware way"
isn't set in stone. It's a combination of how we, as Slackware's user
community, choose to run Slackware and Pat V's whim.
While I generally trust Pat V's whim, I think that his perspective in this
specific case may be biased. What he and his team do to maintain the
Slackware OS is different in some fundamental ways from how the user
community interacts with the system and especially with third-party
software like the stuff on SBo.
Look, nobody here is claiming that dependency resolution is an easy problem
to solve generically for all cases. However, just because it's a hard
problem doesn't mean we should ignore the problem or lie to ourselves and
call it a "feature". Let's acknowledge it.
Dependency resolution is a very hard problem. Nobody else has a perfect
solution for how to do it either.
But just because it's a hard problem doesn't me we have to throw our hands
up and not do anything. Just because there are corner cases and exceptions
doesn't mean that it's useless to even try. This isn't about solving a
problem which may, in fact, be an unsolvable problem. It's about making
that problem a little less annoying in some of the most common and easiest
to handle cases. The vast majority of cases on SBo are low-hanging fruit in
problem space of dependency resolution.
Currently, Slackware's package tools wouldn't even know that dependency
information exists, let alone how to enforce it. And nobody here has
suggested that that should change. All that we're saying is that it would
be nice if it were possible to _partially_ automate the resolution of the
dependency graph. And when you run into those corner cases that everyone
keeps harping on like wx* and different version requirements and optional
dependencies or whatever else, then the it would still be the sysadmin's
role (YOU) to resolve those just as manually as you always did before.
I'm not saying I want portage. If I did I would be using Gentoo instead of
Slackware. I *love* the way that Slackware handle's packages, and I love
how the package tools deal with dependencies (specifically, that they
don't). However I think that having optional tools that help resolve
dependency graphs would still be a HUGE improvement over the
hours-of-tab-hell-using-paper-and-pencil method that we have now. It would
cut out the low-hanging fruit in the process leaving you to just verify the
list and fill in some blanks. Minutes of manual work instead of hours of
On Tue, Jul 10, 2012 at 12:54 AM, Chess Griffin <chess at chessgriffin.com>wrote:
> First, a couple of disclaimers:
> 1. I started the sbopkg project and was soon joined by slakmagik and
> Mauro Giachero, both of whom made sbopkg far better than I ever could
> have done by myself. I retired in 2010 and handed the project over to
> slakmagik who has done a great job in continuing to maintain it along
> with help by Mauro. I thank them both for their past and future help.
> 2. I used to be a SlackBuilds.org admin but also retired from that
> role. I know what it's like to be an admin and to test the submissions.
> It's a lot of work, and what I did paled in comparison to what the
> other admins did, and continue to do. I am not an admin any longer, so
> I don't speak for the SBo project in any capacity.
> Having said that, I think the point made earlier by T3slider that the
> SBo project is not intended to be a do-everything script repository is
> spot on. IMHO, the SBo project is simply intended to provide a
> repository of SlackBuild scripts just like the ones that Pat creates for
> official Slackware packages. Since those official SlackBuild scripts
> don't have any kind of dependency information, neither do the SBo
> scripts (other than what the maintainer decides to put in the README).
> When slackmagik, Mauro, and I came up with the idea of the sbopkg
> queuefiles, the point was to only try to automate what the user would
> otherwise do manually. We've all sat down with a paper and pencil and
> written out our list of SBo packages to build and, after reading through
> the READMEs, figured out the right order of build dependencies. The
> queuefiles is intended to be simply a way to "save" that information to
> make it easier to build the packages again later on. Is sbopkg or its
> queuefiles perfect? Certainly not. But, it really was written with the
> "Slackware way" in mind and I think overall, it works well. Sbopkg
> doesn't try to figure out anything for you -- the user still has to put
> in the initial work -- but sbopkg can make life a little easier by
> saving this information in a simple text file we call a queuefile for
> future use.
> I understand the OP's point and yes, I can see a case where having a
> standardized format for including compile-time dependencies in the
> README or .info file would be helpful. But that's never been the
> Slackware way so putting that in place would move the SBo project from
> its original purpose, at least as I see it.
> Finally, and here is where I put on my "former SBo admin" hat on, if the
> SBo project were to change things and start requiring that build-time
> dependencies be included in the README or .info file, then this would
> definitely lead to more work for the current SBo admins, who already put
> in a lot of time in maintaining SBo. The fact is that many SlackBuild
> script maintainers are not that communicative (and I've been guilty of
> this myself -- I only just now got to updating OpenArena after /many/
> requests -- sorry!) and either the admins would have to try and track
> down all the maintainers to update their submissions to the new format
> or do it themselves. And, of course, test the listed dependencies.
> What if someone forgot to add a dependency? Each submission would have
> to be tested on a clean, newly installed system in a VM or something to
> ensure that the dependencies were listed correctly and in the right
> order. That's a lot of work.
> Ultimately, I think Slackware, and the SBo project, are geared toward
> those who are willing to put in some of their own effort when it comes
> to adding third-party software. I use FreeBSD (and OpenBSD) as well so
> I am familiar with their ports and packages systems. And, for the most
> part, they work well. And I was even a FreeBSD port maintainer for
> awhile. But those systems were built with that kind of dependency
> tracking from the outset and Slackware SlackBuild scripts were not.
> Therefore, any such dependency tracking is a bolted-on solution.
> I have no idea if the current SBo admins are considering adding
> dependency information like the OP suggested. Maybe so, maybe not. And
> whatever they decide is fine by me. Either way, I really appreciate all
> the hard work the SBo admins and the SBo Slackbuild script maintainers
> put in. The SBo project is a huge, and I mean HUGE, benefit to the
> Slackware community.
> Just my < $0.02. :-)
> Chess Griffin
> SlackBuilds-users mailing list
> SlackBuilds-users at slackbuilds.org
> Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
> FAQ - http://slackbuilds.org/faq/
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the SlackBuilds-users