Date: Sat, 12 Sep 2009 09:54:33 +0100 From: Matthew Seaman <m.seaman@infracaninophile.co.uk> To: John W <jwdevel@gmail.com> Cc: freebsd-questions <freebsd-questions@freebsd.org> Subject: Re: ports: how to handle 'alternate' dependencies Message-ID: <4AAB61C9.4030005@infracaninophile.co.uk> In-Reply-To: <fa8771800909112306n2a58ff56h5a7bd9e056b062fc@mail.gmail.com> References: <fa8771800909112306n2a58ff56h5a7bd9e056b062fc@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigA7B7EDDFDCB3FEF4ED39C0EC
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
John W wrote:
> I'm just learning the guts of how ports work, and wonder:
>=20
> How do ports specify that "any one of X, Y, Z " would satisfy a depende=
ncy.
>=20
> 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.
>=20
> But how would I alter graphics/jalbum to say, essentially, "either
> jdk16 or diablo-jdk16 is required"
>=20
> 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+=3D ${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 mechan=
ism
for specifying what version(s) can be used with each port, possibly a=
corresponding user settable flag for choosing what should be installe=
d,
and frequently a mechanism for feeding back into the ports system wha=
t
version /was/ installed.
Lets take perl as an example. Currently there are two, pretty much f=
reely
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 wi=
th a=20
dependency on perl and perl was not previously installed and you have=
n't=20
made a deliberate choice to install one or the other. However, you c=
an
opt to use perl5.10 simply by installing it -- or more likely, as per=
l 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 d=
epend
on perl5.10 and if you build your own INDEX, perl5.10 will appear eve=
rywhere
in the dependency listings. The reason is that perl adds text like t=
he
following to /etc/make.conf:
# added by use.perl 2009-09-12 09:04:56
PERL_VERSION=3D5.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 aw=
ay. This
works because ports that depend on perl generally contain the magic i=
nvocation
like:
USE_PERL=3D yes
or
PERL_CONFIGURE=3D yes
which ultimately have the effect of causing /usr/ports/Mk/bsd.perl.m=
k to
be included and parsed during a make(1) invocation. The PERL_VERSIO=
N
variable is examined in there and used to modify various *_DEPENDS l=
ines
amongst other things.
In fact, the majority of the files under /usr/ports/Mk exist to prov=
ide this
sort of alternate dependency capability for the sort of commonly use=
d=20
software packages that the majority of everything else relies upon.
Perl is slightly unusual in that at the moment either of the perl ve=
rsions
is compatible with any perl dependent ports in the tree. There's no=
t much
perl-5.10 specific code readily available anywhere. More frequently =
ports
will need a specific version or versions of a dependency, and the ty=
pical
mechanisms for specifying that work like the following. The port ma=
intainer
can indicate that a port depends on a popular software system and wh=
at
dependency versions are compatible with it by including a USE_FOO va=
riable,=20
possibly with additional variables to control various behaviours:
USE_MYSQL=3D yes
IGNORE_WITH_MYSQL=3D 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=3D 50
There are any number of variations on how all this sort of stuff wor=
ks
in detail, depending on the needs of individual ports. There's a l=
ot of
documentation in the Porter's Handbook and the various makefiles in =
/usr/ports/Mk/ are extensively commented. Simply copying what anoth=
er
port does is a good starting point.
=20
Cheers,
Matthew
--=20
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
Kent, CT11 9PW
--------------enigA7B7EDDFDCB3FEF4ED39C0EC
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.13 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEAREIAAYFAkqrYc8ACgkQ8Mjk52CukIxnRwCeJF2ydl+eRe8D9XAr8F/cbnuZ
76wAnRtszNGeVOUsfIlnMc6Mvc9gzdUj
=xNbN
-----END PGP SIGNATURE-----
--------------enigA7B7EDDFDCB3FEF4ED39C0EC--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4AAB61C9.4030005>