Hi, I think this is a nice idea. It could take inspiration on what is done by other package systems. Citando Weissmann Markus :
Hi all,
here is a proposal to solve the "I don't like the program X to be called Y" problem. This problem normally looks like: A prefers Python 2.4 to be called when "python" is executed, while B prefers Python 2.5 in this case. Meanwhile C complains that for a silly python script a while python installation is compiled on his poor G3 ibook when there is Apple's python which would work just fine. I already saw the same pattern for gcc, coreutils, gnutar, sed, swi- prolog, etc.
For the third case, the "old" dependency sheme permits this : rubber depends on a binary called python, but not explicitly the one provided by python23 which was the latest at the time of the first portfile for rubber. For the first case, it looks like pkgsrc's /etc/mk.conf which can contain 'PYTHON_VERSION_DEFAULT=24' (or 25).
To overcome this, we should install tools much like Apple's "gcc_select" which own the executables (e. g. ${prefix}/bin/python) and perhaps stuff like their manpages (e. g. ${prefix}/share/man/man1/ python.1.gz). They will carry the generic name as portname (e. g. Python). When their script is called, they take the version number (or special name - swi-prolog vs. swi-prolog-lite), check if the special files (e. g. ${prefix}/bin/python2.5 and ${prefix}/share/man/ man1/python25.1.gz) are there and then switch it's symlinks to the version specified. In the default case, they would point to Apple's version of the tool - if available. It is also possible to switch to that version:
$> python -V Python 2.3.5 $> python_select 2.4 $> python -V Python 2.4.3 $> python_select 2.5 Python 2.5 is not installed! $> port install python25 $> pythjon_select 2.5 Python is now Python 2.5 Python 2.5 $> python_select apple $> python -V Python 2.3.5
It would be nice if we wouldn't just create multiple tools for all of our applications (gcc, python, etc.) but rather find the common pattern here. These tools should be installable as normal ports and not be part of the base port system. As an implementation idea: Perhaps creating a generic "select" tool that reads a config file depending on the executables name. The config file would have the possible interpreters/compilers/.. and their respective files to symlink to.
And you would call it port_alternatives, just like pkgsrc's pkg_alternatives or debian's alternatives. 'pkg_alternatives change vi vim' says that the meta vi is now provided by vim. Both use a config directory that contains symlink to the selected programs providing the alternative. And the main link points to the config directory. The added value here would be the possibility to select apple's tools. So, python, editor, gcc, ruby, perl would already have available alternative, whereas text-browser would not. One point it raises is the fact that some ports *provide* some functionality (browser for example, sql database for another one) and that other port may depend on that functionality. This point is similar to the idea of a virtual postgresql or mysql package provided by one of the numerous available ports, and ports being able to depend on that virtual package whose variants tell to which of the possible port to link the mysql to be used.
I'm currently out of time, so if someone would like to implement this, please shout out loud, so we can find a place to develop this. Perhaps this could even be a small to medium task for GSoC?
Sorry, not me, but I would be interested that it be implemented.
cheers,
-Markus
PS: This would of course mean, that calling ${prefix}/bin/python will execute in some random interpreter! Please, if your port relies on a specific version of e. g. Python, please specify this _explicitely_ (call e. g. ${prefix}/bin/python2.4).
Emmanuel