On 10/07/2012, at 5:02 PM, LukenShiro wrote:
Il giorno Tue, 10 Jul 2012 10:42:10 +1000
Christoph Willing <c.will...@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@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
_______________________________________________
SlackBuilds-users mailing list
SlackBuilds-users@slackbuilds.org
http://lists.slackbuilds.org/mailman/listinfo/slackbuilds-users
Archives - http://lists.slackbuilds.org/pipermail/slackbuilds-users/
FAQ - http://slackbuilds.org/faq/
