[Slackbuilds-users] requirements in README files

[Christoph Willing]

On 10/07/2012, at 5:02 PM, LukenShiro wrote:

> Il giorno Tue, 10 Jul 2012 10:42:10 +1000
> Christoph Willing <c.willing at uq.edu.au> ha scritto:
>> 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).
>
> I am not absolutely against this idea, but it is not so simple.
> First, there are several types of prerequisites:
> - mandatory build dependencies;
> - optional build dependencies;

The PREREQS="..." line, as I use it already, is only used for build  
dependencies.

Let me say right now that I suggest this mechanism largely because I  
have been using it myself for some time. In the lab that I'm  
responsible for, we have many specialist softwares that have various  
build dependencies. I have a number of my own build scripts which  
specify the build depenednecies but over the last year or so I have  
been modifying SBo scripts (when they already exist) to include a  
PREREQS= line in the info file. If PREREQS were already included, I  
wouldn't have to maintain my own versions of them. However the effort  
in doing so is worth it, so I do.

I general, the PREREQS field is most useful for mandatory build  
dependencies - my unsubstantiated guestimate is that this probably  
covers about 80-90% of all cases. Other cases can be dealt with  
specifically in the .SlackBuild script itself. However even if an  
optional dependency is listed in PREREQS but not actually used (i.e.  
we needlessly treat even an optional dependency as mandatory), so  
what? Its just another package that happens to be installed while  
you're building - whether its used or not. In general, any given  
system has probably hundreds of packages installed that are not needed  
to build a particular software package.


> - mandatory runtime dependencies;
> - optional runtime dependencies;

I believe runtime dependencies should be a different topic. I don't  
use the PREREQS= entry for that.


> - build and/or runtime dependencies who relies on one o more flags
>  users can pass to .SlackBuild.

As above, an SBo author could also "blindly" treat any optional build  
dependencies as mandatory and include them in the PREREQS field.  
Whether such optional dependencies are actually used could depend on  
flags passed to the .SlackBuild


> To complicate the scenario ;) upstream developers sometimes use  
> library
> auto-detection in their configure files, so maybe it should taken into
> the account, too.

Setting up a useful PREREQS field can actually make use of that  
mechanism i.e. as a configure script fails due to a missing package,  
that package can be added to the PREREQS field. If the PREREQS field  
is used to ensure that its members are installed at build time (after  
all, this is the purpose of the PREREQS field) then the previously  
missing package will be installed next time the build script is run.  
After dealing with a number of such failures, a reliable PREREQS field  
will have been constructed. By the time such an SBO script reaches an  
ordinary user, it will just work because all the build dependencies  
have already been transparently specified.


chris


>
> Moreover, it would also make sense to note reverse dependencies (a
> prerequisite upgrade, particularly for a shared library, often
> entails a new compilation of packages who uses it).
>
> -- 
> GNU/Linux * Slackware64 current/multilib
> LU #210970 SU #12583 LM #98222/#412913
> _______________________________________________
> SlackBuilds-users mailing list
> SlackBuilds-users at slackbuilds.org
> http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
> Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
> FAQ - http://slackbuilds.org/faq/
>

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