Re: Bug#133306: apt-listchanges: Does not handle .pyc files correctly
On Mon, Feb 18, 2002 at 12:48:02PM -0500, Matt Zimmerman wrote:
> On Mon, Feb 18, 2002 at 12:33:55PM +0100, Christian Kurz wrote:
>
> > On 17/02/02, Matt Zimmerman wrote:
> > > and this one package with one set of install/remove scripts supports
> > > emacs20, emacs21, xemacs21. When a new emacs is installed, the
> > > installed elisp packages are byte-compiled for it, and when one is
> > > removed, the byte-compiled files are removed. These packages don't have
> > > to build-depend on any emacs, much less multiple versions (as with these
> > > python packages).
> >
> > Well, but why can't you then use one generic install and remove script and
> > pass it not only the version number but also the package name and let it
> > then handle the byte-compiling? It would remove the need to add mostly
> > identical scripts to the packages and therefor make it easier to maintain
> > the packages.
>
> Good plan; why not do that for python? How about a
>
> /usr/sbin/python-pkgtool --install <package>
> /usr/sbin/python-pkgtool --remove <package>
>
> Which will have knowledge of which python versions are installed, and
> byte-compile/purge the appropriate files. That way, the logic about which
> versions are installed, and the details of byte compilation, stay out of
> module package maintainer scripts.
>
> One detail that needs to be handled is to only make the package available
> for the python versions that it works with. I don't like having multiple
> packages; for pure python modules the code often seems to work with multiple
> versions of python.
Objection 1: Autocompilation can result in progams that compile but
do not work as expected.
Examples: scope rule changes. Inheritance Changes. Arithmetic Changes.
To my mind, all of these are issues that require human intervention
or understanding, and simply autocompiling scripts will not detect
problems. In particular, nested scopes are now default in 2.2 and
were not available at all in 1.5.2. This is bound to have some
interesting consequences.
Simile with the "embed the ring of integers into the field of reals"
fiasco.
Objection 2: Autocompilation can produce programs which fail to
compile.
Examples. <op>=, use of mimelib (not available in 2.2), type/class
unification, use of iterators/generators, etc.
Some of these would be easy to backport to 1.5.2 (although probably
not worth the effort), Certainly all would require a human decision.
Objection 3: None of this addresses the case of 'C'-extension modules.
Looking at my site-python2.1, I am guessing that this affects from 25%
to 50% of all modules. These have to be hand-created with multiple
packaging anyway.
Objection 4:
This is a minor objection: It would not be unusual to have at least
two versions of python installed. (I currently have 3). I keep only
current as a "full featured" package. I DO NOT want to have every
package auto-installed and auto-compiled in every python on my system!
Concluding remarks:
It is simply not all that hard to create multiple python packages.
This proposal simply offloads a minor amount of work from the packager,
and a certain amount of storage from servers replacing it with greater
package installation time and greater local storage use.
Worse, it hides problems from the packager. If the package compiles and
works under the current python, I suspect that most developers will do
no actual testing under old or leading edge pythons. And if they have
not, the user contract is being violated. The packager may easily manage
to inadvertantly install a broken package!
Finally, the emacs compilation process is one reason that I make very
sure that no emacs packages are installed on any of the systems I have
control over. I find the compilation process to be at best annoying,
and at worst a near denial of service. I would not welcome it in
python.
Jim Penny
>
> --
> - mdz
>
>
> --
> To UNSUBSCRIBE, email to debian-python-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
Reply to: