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

[Jim Penny <jpenny@debian.org>]

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 ...]
> 
> WoW! how complicated is that! People are not going to dare install Python or
> Python packages because of the barage of options that gets thrown at them.
> 
> The whole reason the current Python Policy went down the "default version +
> optional particular versions" is it simplifys everything for people who just
> want Python with working Python modules, but allows people to still
> install/package unusual stuff for particular versions of Python without
> breaking everything.
> 
> 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.

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".  

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.

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.

Jim Penny

> 
> I'm going to look at the Python central stuff right now... more
> comments/suggestions to come :-)
> 
> -- 
> ----------------------------------------------------------------------
> ABO: finger abo@minkirri.apana.org.au for more info, including pgp key
> ----------------------------------------------------------------------
> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-python-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>