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

[Mike Porter <mupi@xxxxxxxxx>]

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

On Monday 06 October 2003 10:21 am, Matthew Dillon wrote:

>     Heh.  With X thousand ports in the system it can happen.
>
You have a point.  However, we are also talking about several versions of 
libraries, not necessarily things like, 47 version of gcc or perl, or Xfree 
or ? 

>     This could be done as a post-install step.  The packaging system would
>     record what you specifically requested and the packaging system knows
>     what the run-time dependancies are, so it should be able to calculate
>     which packages remain (were compile-time or install-time dependancies
>     only).
>
Yes, although hopefully the need for this would minimized by keeping 
relatively up to date programs as the 'normal' compiler/perl version (which 
are the main compile-time and install-time dependencies, AFAICT...)

> :
> :This is a potential issue, however, most often, when a library is
> : upgraded, it retains backwards compatibility with previous versions. the
> : trick is to be able to know which ones actually do this, and create a
> : 'range' of acceptable dependencies ("this package requires glibc version
> : 6.2 or greater" for example, or "this package requires glibc version
> : 5.4-6.8".    Only if glibc exceeds 6.8 would there be a need for two
> : copies of glibc...and chances are there may be a program with a max
> : version of 5.6, and we can kill two birds with one stone by having glibc
> : 5.6.  the logic for determining this, of course, must be provided by the
> : ports system, and has no real bearing on the underlying framework.
> :
> :mike
>
>     The problem is that even the authors of the libraries often get it
> wrong. The only safe solution is to require everything to be versioned and
> to not automatically upgrade dependancies until someone has actually gone
> in and physically built the package with the new library to verify that it
> still works.
>
That's why I said "the trick is to know which ones *actually do this*".  My 
idea would be that the portfile could specify a range of ports useable, and 
the installer can check to see if one of those versions is already installed.  
The only concession I make to ease the port maintainer's workload is to 
assume that the version will work until proven otherwise.  What you suggest 
is that we should assume it won't work, until proven otherwise. (in my 
version, 'lib_x_maxversion' would be 'latest' until we encounter a problem; 
in your version, it would be the latest version known by the maintainer to 
work.  Your way is safer (you won't get ports that refuse to work, unless 
there is a problem retrieving the older version) but is more work for the 
maintainer (if a new glibc comes out, the maintainer would need to check 
functionality of his ports to see if they still work, to (hopefully) minimize 
the duplicate versions present on a machine   My way of doing things is less 
work for th emaintainer, but will likely result in broken ports from time to 
time.)

INcidentally, the idea of explicitly setting a version list for dependencies, 
and having multiple libraries present, opens the idea that a maintainer could 
specify different sets of patches for different versions of dependencies (if 
version x of libsomelib is present, use patchset A, if version Y is present, 
use patchset B.  If neither version is present, prefer to get version x, if 
available).   Of course, part of the advantage behind allowing a newer 
compiler for ports/packages is the idea that it is less work for the porter, 
if we start adding a whole pile of new features, we negate some of that 
advantage.  Also, while we clearly will need to have our own set of ports, I 
would love to see our port system be able to use portfiles from FBSD. making 
the necesary assumptions for them (about things like gcc versions and library 
versions that may be present....this may wind up being too much work, but it 
would be a nice feature...)


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

iD8DBQE/gjV1Y30jZzkECLcRAnL3AJ0ahXC64bwyqwhSKToz8UYuzUrVEQCcC9fA
9IN7lhCIm1kdLSzfoJgCfT8=
=6ITB
-----END PGP SIGNATURE-----