[Slackbuilds-users] requirements in README files

[Christoph Willing]

On 11/07/2012, at 2:01 PM, J wrote:
[snip]
> 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  
> have.

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:

. myApp.info
for package in $PREREQS ; do
   check_something_about $package ;# is it installed, for instance?
   # do anything else relevant to $package
done

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  
build requirements.

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  
work.


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.


chris


Christoph Willing              +61 7 3365 8316
Research Computing Centre
University of Queensland