[Slackbuilds-users] requirements in README files
c.willing at uq.edu.au
Tue Jul 10 00:42:10 UTC 2012
On 10/07/2012, at 8:57 AM, Greg' Ar Tourter wrote:
> sbopkg has a queue file facility which allows your to create list of
> package to build in a certain order. Mauro used to maintain a
> repository of queue file for all packages available in slackbuilds.org
> but I suspect he has been busy with other things lately. you can get
> the queue files from http://gitorious.org/sbopkg-slackware-queues/.
> Adding dependency management is the not slackware way of doing thing
> and it is a can of worm that most people here would not want to see
> open. Slackbuilds.org follows very closely the way Slackware works and
> the slack-required file is not part of slackware package standard and
> therefore doesn't really have a place in the slackbuild packages made
> available here.
Neither is a .SlackBuild file part of a regular Slackware package, yet
every SBo .SlackBuild I've seen contains the line:
cat $CWD/$PRGNAM.SlackBuild > $PKG/usr/doc/$PRGNAM-$VERSION/
In principle then, its not against the law to include additional files
or information that may or may not be useful to the average user.
Therefore we could leave other potentially useful information in /usr/
doc/$PRGNAM-$VERSION (for instance) too, couldn't we? It could be in a
separate file or added to an existing README. It could be laid in a
regular format so that interested software and humans could easily
parse it. It could be completely ignored by disinterested parties (as
I suspect the included .SlackBuild is ignored 99.73% of the time).
A listing of build prerequisites is even more innocuous - no
particular need for that to appear in a final package at all. My
suggestion would be for a PREREQS="..." line in the .info file (which
doesn't by default appear in the final package).
> As T3slider mentions, dependency resolution is extremely complex and
> rarely done well. In addition to optional vs mendatory dependency,
> some compile options may be required for some and not for other. (I am
> thinking in particular about some package which will not build if wx
> widgets is compiled with UTF-8 support).
For software whose build (or runtime) requirements are beyond human
understanding, a listing of the requirements could just be omitted or
you could ignore it (recall, none of this is compulsory). In that
case, you're no worse off than you are now building that particular
package that needs a non UTF-8 wxWidgets.
Christoph Willing +61 7 3365 8316
Research Computing Centre
University of Queensland
More information about the SlackBuilds-users