Re: Bug#128957: *.py[co] files are architecture independent

[Matthias Klose <doko@cs.tu-berlin.de>]

Matt Zimmerman writes:
> On Sun, Jan 13, 2002 at 10:00:23PM +0100, Matthias Klose wrote:
> 
> > - wajig uses /usr/bin/python as interpreter and therefore should
> >   depend on "python (>= 2.1), python (<< 2.2)". Same for the build
> >   dependency.
> 
> Why is python (<< 2.2) necessary?  apt-listchanges, for example, was
> developed for and tested with both python2.1 and python2.2, so I used a
> dependency of python (>= 2.1).

looking at the package, it's probably not necessary. But why should it
run with any python version? The package is mostly tested with
Debian's default python version, which is (and will be) 2.1 for woody.

apt-listchanges is a special case, because it alway runs as root and
does not rely on third party python packages which are not avilable
for some python version. Assume, that you run apt-listchanges with
1.5, then the .py file get recompiled for python-1.5 (if you do NOT
run as root) every time, assuming they were compiled with 2.x before.
There is currently no way to switch off python's side effect of trying
to write compiled files.

For apt-listchanges this doesn't look very harmful, but consider the
current packaging of the mailman package (where I disagree with the
mailman maintainer ;-):

- mailman does not depend on a particular python version (because it
  runs with versions from 1.5 and up).

- assume, you install mailman, having python-1.5 as your default
  interpreter. The python files get compiled for 1.5.

- you install python-2.1.

- mailman is a cgi application, running with www-data.www-data, so
  now every time you call the cgi, thousends of lines are recompiled,
  but not saved.

- so instead of choosing one python version, the mailman maintainer
  gives the user the "freedom" to choose one python version, and
  charges him with excessive runtime.

- In an ideal world, we would have a recompilation of python files for
  every application an an own python interpreter (alternative) for each
  application. But we currently don't have ...

In the case of apt-listchanges you should take care of removing any
compiled *.py files in the postrm.

Hope this helps ...

	Matthias