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

Mike Porter mupi at
Sun Oct 5 23:49:10 PDT 2003

Hash: SHA1

On Saturday 04 October 2003 12:52 pm, Hiten Pandya wrote:
> Sander Vesik wrote:

> 	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 

> 	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 

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

Version: GnuPG v1.2.1 (FreeBSD)


More information about the Kernel mailing list