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

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:> 	Hmm, 47 different versions of the same *ONE* software is what we
:> 	are limiting ourselves with at the moment.  But if you think
:> 	about this in a recurring way, we could end up using a lot of
:> 	disk space, wether we hide it or not.
:>
:Agreed.  Nobdoy was seriously considering that anybody would actually have 
:that many, although it could be theoretically possible given sufficient disk 
:space.

    Heh.  With X thousand ports in the system it can happen.

:> 	From what it looks, the whole idea does not space conservative,
:> 	but heck, prove me wrong I say. 8-)
:>
:The idea is not necessarily to conserve disk space, but to make the 
:appropriate tools available, if necessary.  This is why I think the option to 
:remove packages which are installed as a 'compile time' dependency is a Good 
:Idea.

    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).

:> 	In a scenario where you need to install a package which has
:> 	multiple dependancies, with sub-deps, it is going to result
:> 	in a huge mess.  I am assuming that the sub-deps will have
:> 	their own particular dependancy requirments thus giving us
:> 	lots of packages.  Hiding them will not make any difference
:> 	space wise.
:>
: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.

    This isn't as bad as it might seem.  A good packaging system should be
    able to manage multiple versions of things and be able to tell you
    when an older version of something can be physically removed from the
    system.  If you did not request that *that* particular version of 
    the package be installed, then it can be removed when upgrades remove
    remaining dependancies on it.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>