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
