OK, I am clearly not going to persuade you how wrong-headed ;-) you are, so proceed.
Please use the debconf model. If there are enough clear benefits, both packagers and administrators will want to use your system. Here is something that would make this enormously more palatable to me. Event: installation of module foo -- the system looks to see which pythons are currently installed, and gives you a checkbox system that looks like: ============================================================ install module for python version number (not listed implies installation when/if a version of python not in the list is installed) module_name __________________________________________________________ foo D 1.5.x I 2.1.x ? 2.2.x ? Pythons not listed D means that the version is incompatible and cannot be installed. I means that the version is known working and should be installed. ? means that the version has not been tested but will be installed unless you replace this with N. N means that the administrator or packager previously asked that this module not be automatically installed for this version. ============================================================ Event: Installation of a new version of python (is this needed for a new point release? I don't think so). To make ascii easier, I will assume 1.5 and 2.1 are installed. And we are installing 2.2. ======================================================================== install module for python version number (not listed implies installation when/if a version of python not in the list is installed) module_name __________________________________________________________ bar D 1.5.x I 2.1.x ? 2.2.x N Pythons not listed baz D 1.5.x I 2.1.x D 2.2.x ? Pythons not listed foo D 1.5.x I 2.1.x I 2.2.x ? Pythons not listed ... ============================================================ The administrator whould be able to change, at least, any value for (in this case 2.2) the version being installed, and future pythons. Same meaning as above. Oh, and the administrator must understand that c-extension modules cannot be upgraded, held, etc. in this manner. reasons: this seems like a modest amount of work if the modules are installed piecemeal, as the need is recognized. Administrators should be willing to put up with it. It gives adminitrators warning that they are installing untested modules, and should be prepared to accept breakage. It should not be unduly onerous on pure python module packagers. Another idea: This should be ready to accept pure python scripts (installed in /usr/bin typically), as well as python modules. Essentially this comes down to editting the first line of the script (#!/usr/bin/pythonx.x). A script can run only under one python, obviously. So, it must behave more as a radio button than a checkbox, ... How does the registry know the initial value (I,D,?,N) to put in for a given module and version of python? Is a new control section required for this scheme (something like tested for: )? Presumbly conflicts can be used for state D. For python scripts, can Recommends: be used to set the prefered python? What if the preferred python is not installed? Jim Penny