Re: Bug#133306: apt-listchanges: Does not handle .pyc files correctly

[Jim Penny <jpenny@debian.org>]

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