Re: Bug#133306: apt-listchanges: Does not handle .pyc files correctly
On Mon, Feb 18, 2002 at 07:28:41PM -0500, Jim Penny wrote:
> On Tue, Feb 19, 2002 at 11:00:53AM +1100, Donovan Baarda wrote:
> > On Mon, Feb 18, 2002 at 06:31:49PM -0500, Jim Penny wrote:
> > > 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.
> > [... snip heaps of stuff ...]
[...]
> > The stuff about version-independant Python modules is there because there
> > _might_ be a simple way to make packages that nicely work for multiple
> > versions of Python. However, if there is _not_ a simple way, and it starts
> > to complicate things for the "Just Python + Python modules" people, then
> > it's not worth doing.
>
> Please do so. But, from what I am hearing, the just autocompile
> crowd wants the impossible. They want "just python + pure python modules"
> to "just work", even though there are fundamental differences between
> python releases. Yes, 95% of pure python modules are in fact going
> to work, right now, since they were written in 1.5.2, and 2.x is
> _mostly_ backward compatible. But that situation is not for long.
> Already I have seen scripts that are hard to backport to 1.5; and
> 2.2 has features that are going to be real hard to backport to 2.1.
I have a feeling they have thought about it a bit more than that... There
are the people like me and you who throw in sometimes legitimate and
sometimes wildly inacurate off the cuff comments, and then there are the
people actualy doing it, who don't say much but have hit all the problems we
are just dreaming up already :-)
> But no regime at all is being considered for semantic breakage;
> at most, the current things that I am seeing only consider breakage
> at the "won't compile" level. I see nothing that addresses issues
> like "inheritance model is changed", "scope rules are changed", or
> "arithmetic operator / has a new meaning".
IMHO all breakages will require human intervention to resolve. Any scheme
that does attempt to autocompile pure-python modules for a variety of Python
versions must include a mechanism for packagers to specify a range of valid
Python versions.
> Note that the "python + python modules" is not even addressed under
> these proposals. This is an oversimplification. They address only
> "python + pure python modules", which is a far smaller set.
I believe "python + python modules" is already handled by the existing
Python Policy. All this autocompile work is, I think and hope, only
targeting that small subset of pure python modules, and only those that can
work for more than one version of Python.
> If you are going to autocompile, at least give the savvy administrator
> some way to opt out, and to know which pythons the packager has actually
> tested against. If you have a simpler policy, fine. But, "lets release
> a new python, and see what bug reports come in when scripts suddenly
> fail to compile or when scripts suddenly give different answers" seems
> like an inadequate policy to me.
I would be far harsher than this. I would say that packagers have a
responsiblity to ensure their pure python modules are compiled against only
the versions of python that are known to work. This way the savy
administrator can explicitly dance with disaster by compiling his own
against other versions in /usr/local/ somewhere.
--
----------------------------------------------------------------------
ABO: finger abo@minkirri.apana.org.au for more info, including pgp key
----------------------------------------------------------------------
Reply to: