[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: dh_python and python policy analysis


        I have some more thoughts to offer on the example Steve
 presented:  in essence, he is talking about a package that has become
 incompatible with the version that was in stable.

On Sun, 13 Aug 2006 23:03:13 -0700, Steve Langasek <vorlon@debian.org>

> On Sun, Aug 13, 2006 at 07:56:09PM -0500, Manoj Srivastava wrote:

> Now, introduce version 2.0 of python-foo.  Because upstream
> considers python 2.3 obsolete, they have begun using language
> features in their module (internally, not as part of the module
> interface which remains unchanged) that are specific to python 2.4
> and above.

        This could happen to _any_ package written in any other
 language.  Policy does not go out of its way to protect the reverse
 dependencies of a package that breaks compatibility between stable
 and testing -- were the package written in any other language.  Why
 should Python be treated differently, if it makes for more uploads and
 makes Python transitions slower?

        What _do_ we do in other cases? There is precedence for
 creating a brand new package, called foo2 (X100/11, f;ex, apache,
 fvwm, and a load of others) so that new users can use the new
 functionality, while users of older package have time to transition.
 Maintainers can modify packages for Debian to retain compatibility.
 Or, worst case, we shrug and tell people that sorry, not in all cases
 can one maintain compatibility, so people should change the

        I see no reason to go to heroic measures just for the sake of
 packages programmed in Python as opposed to, say, C -- given the
 drawbacks I have already mentioned in previous posts.

A nuclear war can ruin your whole day.
Manoj Srivastava   <srivasta@debian.org>  <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Reply to: