ports: how to handle 'alternate' dependencies

[Matthew Seaman]

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20090912/56b804e2/signature.pgp