John W wrote:
I'm just learning the guts of how ports work, and wonder:

How do ports specify that "any one of X, Y, Z " would satisfy a dependency.

For instance, when I build graphics/jalbum, it says it requires jdk16.
I would rather use diablo-jdk16, since I find it faster and it is
easier to install.

But how would I alter graphics/jalbum to say, essentially, "either
jdk16 or diablo-jdk16 is required"

Generally, how to handle the case when a port requires X, but there
are multiple implementations of X that can perform the job, and any
will suffice?
I feel like this issue must come up from time to time, what is the
right way to deal with it?
I didn't see any mention of this in the porters handbook...

This is a quite tricky area.  First thing to realise is that a dependency
line like this in a port:

RUN_DEPENDS+=   ${LOCALBASE}/sbin/suphp:${PORTSDIR}/www/suphp

says that the port needs ${LOCALBASE}/sbin/suphp in order to run.  The
port will be satisfied if there is any executable file of that name in
place -- there's no check that the file belongs to any particular port
or even to any port at all.  If the test file is not found, then the
second part of the dependency line just indicates an example of a port
that when installed will provide the dependency.

Now, for most of the dependency lines shown explicitly in port makefiles,
there isn't any ambiguity here: there's only one port available that can
fulfil the dependency.  Job done.

Where there are multiple choices, you see two different scenarios:

 * Ports with 'devel' variants or multiple release versions, but that
   only have a few dependents.

   In this case, if you want a non-standard version, simply install
   it first, before trying to install the dependent port.  This will
   work just fine from the point of view of the software operating
   correctly, although it can confuse ports management tools, which
   have been known to continually try and substitute the listed
   dependency.

 * Foundation ports -- things like Apache, MySQL, OpenLDAP, autoconf,
   Java, perl, python. Here there are hundreds or thousands of possible
   dependents.  In these cases, typically there will be a special mechanism
   for specifying what version(s) can be used with each port, possibly a
   corresponding user settable flag for choosing what should be installed,
   and frequently a mechanism for feeding back into the ports system what
   version /was/ installed.

   Lets take perl as an example.  Currently there are two, pretty much freely
   interchangeable, versions of perl available in the ports:

       /usr/ports/lang/perl5.8  --- perl-5.8.9_3
       /usr/ports/lang/perl5.10 --- perl-5.10.1

By default, you'll get perl5.8 -- that is, if you install anything with a dependency on perl and perl was not previously installed and you haven't made a deliberate choice to install one or the other. However, you can
   opt to use perl5.10 simply by installing it -- or more likely, as perl is
   pretty fundamental to the system and tends to be installed just about
   everywhere by replacing perl5.8 with it.  eg:

       # portupgrade -o lang/perl5.10 -f perl-5.8.9_3
       # portupgrade -x perl-5.10.1 -fr perl-5.10.1

   After doing this, any perl-dependent ports you install will happily depend
   on perl5.10 and if you build your own INDEX, perl5.10 will appear everywhere
   in the dependency listings.  The reason is that perl adds text like the
   following to /etc/make.conf:

       # added by use.perl 2009-09-12 09:04:56
       PERL_VERSION=5.10.1

   In principle you could add this variable definition to /etc/make.conf before
   ever installing perl in order to get the version you want straight away.  
This
   works because ports that depend on perl generally contain the magic 
invocation
   like:

        USE_PERL= yes

   or

        PERL_CONFIGURE= yes

    which ultimately have the effect of causing /usr/ports/Mk/bsd.perl.mk to
    be included and parsed during a make(1) invocation.  The PERL_VERSION
    variable is examined in there and used to modify various *_DEPENDS lines
    amongst other things.

    In fact, the majority of the files under /usr/ports/Mk exist to provide this
sort of alternate dependency capability for the sort of commonly used software packages that the majority of everything else relies upon.

    Perl is slightly unusual in that at the moment either of the perl versions
    is compatible with any perl dependent ports in the tree.  There's not much
    perl-5.10 specific code readily available anywhere. More frequently ports
    will need a specific version or versions of a dependency, and the typical
    mechanisms for specifying that work like the following.  The port maintainer
    can indicate that a port depends on a popular software system and what
dependency versions are compatible with it by including a USE_FOO variable, possibly with additional variables to control various behaviours:

         USE_MYSQL=      yes
         IGNORE_WITH_MYSQL=      323 40 41

    The user can frequently use a 'WITH_FOO' variable in /etc/make.conf, or
    make a selection via an OPTIONS dialogue to choose their preference:

         WITH_MYSQL_VER= 50

    There are any number of variations on how all this sort of stuff works
    in detail,  depending on the needs of individual ports.  There's a lot of
documentation in the Porter's Handbook and the various makefiles in /usr/ports/Mk/ are extensively commented. Simply copying what another
    port does is a good starting point.
Cheers,

        Matthew

--
Dr Matthew J Seaman MA, D.Phil.                   7 Priory Courtyard
                                                Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey     Ramsgate
                                                Kent, CT11 9PW


Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to