[Slackbuilds-users] requirements in README files

[Christoph Willing]

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/ 
$PRGNAM.SlackBuild

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.


chris


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