[Slackbuilds-users] requirements in README files
chess at chessgriffin.com
Tue Jul 10 04:54:27 UTC 2012
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
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
Just my < $0.02. :-)
More information about the SlackBuilds-users