variant symlinks (was Re: Anybody working on removing sendmail from base?)

[Mike Porter <mupi@xxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 01 October 2003 07:48 pm, Justin C. Sherrill wrote:
> Mike Porter <mupi@xxxxxxxxx> wrote in
>
> news:200310011747.49198.mupi@xxxxxxxxx:
> > If I was looking through /usr/local/, I would be able to
> > see whatever is installed /usr/local/gcc-2.95.4 and
> > /usr/local/gcc-3.4.n, and know that by setting $GCC_VERSION I could
> > type, e.g., 'set GCC_VERSION=2.95.4; gcc --version' and get "2.95.4"
> > then type 'set GCC_VERSION=3.4.n; gcc --version' and get "3.4.n"
>
> 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.

mike
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)

iD8DBQE/e96sY30jZzkECLcRAos+AKCoLuDSPU9CldoxJvV3rVl54LN4mQCghlwQ
deYmcnXGRQOFQIL3ykdUx5Y=
=7YKL
-----END PGP SIGNATURE-----