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 _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
