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:
