DragonFly kernel List (threaded) for 2003-10
Re: variant symlinks (was Re: Anybody working on removing sendmail from base?)
:> 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
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
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
:> 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
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.