Re: Bug#133306: apt-listchanges: Does not handle .pyc files correctly
On Mon, Feb 18, 2002 at 01:35:25PM -0500, Jim Penny wrote:
> Objection 1: Autocompilation can result in progams that compile but
> do not work as expected.
> Examples: scope rule changes. Inheritance Changes. Arithmetic Changes.
This has nothing to do with the organization of the packages; either way,
the resulting programs must be tested (or if they aren't, things sometimes
break).
> 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.
This doesn't sound like a problem at all. If a module doesn't compile, but
runs when not compiled, then a compilation failure is simply not a fatal
error.
> 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.
I wasn't exactly proposing a complete replacement for the python policy; my
message was a short comment about one aspect of python module packaging. It
did not address all cases.
> 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!
This would be a simple matter of configuration. One of the benefits of a
centralized scheme is that you can configure preferences like these in one
place, rather than offloading a lot more work onto module packagers.
> 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.
What it does is to offload fundamentally fragile code from maintainer
scripts into a centralized and easily maintained program.
In addition, it has the added benefit of making module packaging easier, and
not cluttering the archive with 3 (or 4, or 5) packages per python module.
> 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!
This is no different from packaging for multiple versions, as above.
> 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.
An exaggeration at best.
--
- mdz
Reply to: