Re: dh_python and python policy analysis
Hi,
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>
said:
> 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
dependencies.
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.
manoj
--
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: