Alternative system for conflicting files

[Rainer Müller]

Blair Zajac wrote:
> MacPorts needs a alternative system so that multiple ports can be installed that 
> provide the same file.

Because nobody else commented on this, I just want to send a short mail 
to show that I agree with you.

> Debian systems have a system, call alternatives.  Take java, which is provided 
> by 5 or so different packages.  There's /usr/bin/java which is a symlink to 
> /etc/alternatives/java which is then a symlink to the real java, 
> /usr/lib/jvm/java-6-sun/jre/bin/java on my system.  There's a 
> update-alternatives binary which is used to update these symlinks.

I never understood why there is an extra level of symlinks. Why is the 
symlink not directly /usr/bin/java -> /usr/lib/.../jre/bin/java? Is 
there any benefit from using /etc/alternatives? I can only think of 
backup purposes where you only save /etc, but as long as the current 
selection is saved in /etc and can be re-applied, this extra level 
should not be necessary.

> http://blog.stevenkroon.com/2006/08/29/debian-update-alternatives/
> 
> We need this for MacPorts.  If we don't come up with a MacPorts solution, then 
> each package that has a conflict will either result in 1) the author not 
> bothering to allow simultaneous installs, which is the easy route or 2) bake 
> their own solution, such as gcc_select and python_select.  The solution for 
> MacPorts should be general enough to subsume gcc_select and python_select, 
> allowing those scripts to become wrappers around MacPort's alternatives.

I fully agree with you. gcc_select and python_select have been more 
workarounds until we get a proper implementation. Well, interim 
solutions often last the longest :-)

It would be good to have a way in the Portfile to register (a set of) 
files as alternatives for a select group. Then a port select command 
could make symlinks (as gcc_select and python_select currently do). Of 
course if there is only one alternative installed for a select group it 
should be automatically selected.

Debian's update-alternatives also allows you to register your own files 
for specific groups which is a nice feature but might be dangerous for 
us. At the moment we try to avoid the use of external dependencies 
because they cause a lot of problems and make it hard to debug things 
(for example people often request to use the python provided by Mac OS X 
itself, but it might be an older version, being patched, have another 
feature set, behave differently etc.).

But to make such a system fully usable, a better dependency engine would 
also be needed. So one can specify a dependency on python>=2.4 and any 
port of python{24,25,26,30} will satisfy this dependency.

Rainer