[Slackbuilds-users] requirements in README files
c.willing at uq.edu.au
Wed Jul 11 05:56:42 UTC 2012
On 11/07/2012, at 2:01 PM, J wrote:
> 1. how does such a recommendation get communicated to slackbuild
> maintainers? admins out there, would you be willing to publish such
> a recommendation on slackbuilds.org? after all, if it weren't stated
> there, it wouldn't exactly be worth much.
> 2. formatting - newline/tab/multiple-space delimited, any of these
> is easily parseable, so I would be happy with any of these options
> or anything else that is easily parsed. but I do think it makes
> sense to stick with the currently most popular format - otherwise we
> end up with even more different types of formatting than we already
Hey J, in your first email which started this thread you said:
> An ideal solution would be add this info in a file somewhere, for
> example into the .info file. But they would still need to be in the
> README, cause that just makes good sense. So it makes some sort of
> sense to just have them in the README.
As you know by now, I fully support the general thrust of your
proposal. However I don't really follow the logic of how the ideal
place for this information goes from being the .info file to the
README file (especially exclusively, as seems to be suggested). I
think the ideal place is the .info file - exactly where you started out.
So now to the formatting. Apart from satisfying my own idea of "good
sense", another reason that the .info file is the ideal location for
this info is that its already formatted in a manner that makes parsing
just about a non event. The .info file is currently just a bunch of
shell declarations so that after adding a new field something like:
PREREQS="foo bar alpha beta"
it means that any shell script (the Slackware way?) can just source
the .info file and instantly have the build requirements contained in
a shell variable. You can trivially do things like:
for package in $PREREQS ; do
check_something_about $package ;# is it installed, for instance?
# do anything else relevant to $package
Even if PREREQS doesn't exist (since it may not a compulsory field),
the above loop still behaves nicely.
Its such a no brainer - trivial to implement, _all_ of "newline/tab/
multiple-space delimited" are OK, transparent to current build
scripts, _nothing_ to do with run time dependencies ...
Can I also add that others' comments about this proposal creating
additional workload for SBo admins just don't stack up. If the admins
already test each build script, including compilation and package
generation, then surely a comprehensive list of packages needed for
successful compilation makes their job easier - not harder. If some
package is needed but not installed already or mentioned somewhere so
that it can be, then the first compilation test will fail; now add
whatever time it takes to resolve that which is wrong. Surely its
better - faster - to have some clear mechanism for specifying the
Its surely not the admins role to spend time figuring all that out, of
course; its the package maintainers. The admin just sees the list of
prerequisites and ensures they're installed (very easy to script :),
then runs the .SlackBuild. A well described list of build
prerequisites will assist success, however on "fail", return to
maintainer. The clearer the build requirements, the easier the admins
Did I mention that none of this has anything to do with run time
dependencies? We're talking about listing stuff that has to be
installed before you can compile something using an SBo. One way or
another, you have to know what that stuff is - we just want an
"approved", easily machine readable way to list that stuff that you
have to know anyway.
Christoph Willing +61 7 3365 8316
Research Computing Centre
University of Queensland
More information about the SlackBuilds-users