Mike Porter wrote an extended entry about how variant symlinks could handle multiple versions of ports being installed, including a number of special cases like Perl and the modules installed for it.

Mike Porter’s post was in response to something I wrote, so I’ve separated out our comments. Material in italics, I wrote, while normal text is by Mike Porter.

> The one issue I can think of is: if a user types ‘gcc’, which version do
> they get? There’s going to be (possibly) versions brought in through
> ports, for the base system, and by the user.

There would need to be some sort of default brought in from /etc/skel/.login
(or .profile, or .cshrc, or all of the above). Ideally, this would probably
be something like “GCC_VERSION=latest” (or build a special case into the
varsymslink code where if $GCC_VERSION (or $MTA_BASE, or whatever, basically,
if {variant} is not defined, default to latest, and you eliminate at least
one possible problem. ‘latest’ wouldn’t work very well for $MTA_BASE, of
course, but users aren’t likely to make a habit of running, for example,
‘sendmail’ from the command line (plus it won’t work anyway, if we are using
qmail!). (I use $MTA_BASE because Matt has used it in a couple of his
examples). ${mta}-${mta_version} is more reasonable….$MTA would need to
know about /etc/rc.d/mail settings, unless the enviroment created then
persists throughout all logins (it does, doesn’t it, since all logins are run
from there? I’ll have to experiment when I have a minute)

> What happens when you have Perl installed, and a number of CPAN
> libraries? Those libraries are going to be installed for one version of
> Perl, and not another. The same problem from FreeBSD-4, realized
> differently.

This is actually what you want, since the CPAN libraries are generally written
for a particular version of perl. Since the package/ports system is supposed
to be able to specify which version of perl it wants, two things can happen:
1) if you install a CPAN module/library written for a version of perl you
don’t have, it can install it for you, or simply error out. (this acutally
may make more sense than simply auto-retrieving it, since you could
concieveably wind up with many versions of perl (and no ability to run
certain combinations of packages, which you might wish to do). At least, it
should ask ” the package you are about to install wants: perl X, which is not
installed. Do you want to install that version?” (or something) Again,
max_perl and min_perl could be defined, to allow a range of perl versions
allowed, or a case-by-case list.

Logic should be provided to allow compatible CPAN modules to live in
multiple places. for example, my_lib.pl might work with perl 5.6 and 5.8,
while the files can be installed in /usr/local/perl/5.8/wherever/modules/go,
links should also be provided for 5.6 in
/usr/local/perl/5.6/wherever/modules/go, as appropriate. This is a matter
for discussion of the ports/package system, I think. FWIW, the same applies
to shared library packages installed for any language, not to mention plugins
and so on for web browsers.

> Having to set the correct link at the user level could just be an
> intense headache, especially since there would be additional program
> versions brought in ‘automagically’ by ports, in theory. Plus, there is
> a certain expectation that the program you install and the program you
> run should be the same thing.

Ideally, you would only need to set the symlink in certain circumstances (when
you need to specify a compiler version, or perl version, for example. most
of the time, this will be taken care of for you in a Makefile. most of the
rest of the time, you want whatever the latest version on your system is.
(especially with perl, since chances are you are trying to run some CGI that
relies on CPAN libraries written for perl 5.9.)

what this does leave up to the package system to do, is doing things like
upgrading from 5.8 to 5.9, where you could either replace 5.8 or install 5.9
in addition. We are going to have to provide logic to deal with that, even
if it is just a couple of lines in /etc/make.conf (port_upgrade=overwrite |
port_upgrade=create, for example. perhaps PORT_UPGRADE=YES or
PORT_OVERWRITE=YES would fit the file format better, though would need
careful documentation.) This whole aspect, though is getting ahead of
ourselves a bit, I think. First we need to get variant symlinks in, and then
see if they live up to the promises we are all making about how wonderful
they are going to be.