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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> <http://www.debian.org/%7Esrivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]