Re: dh_python and python policy analysis
On Mon, 14 Aug 2006 09:36:29 -0500, Manoj Srivastava
<srivasta@debian.org> said:
Hate following up my own message. This is a biased recap of a
discussion Steve ands I had on IRC, and ou should wait his response
before taking my version of the discussion without a grain of salt.
> 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.
Additionally, consider what happens when we have a C library
(Steve said that C libraries are a better fit than, say, flex). If
libselinux comes out with a backwards incompatible change, and the so
version changes, what do I have to do? I have to edit the control
file, create libselinux2 instead of libselinux1; perhaps split off
a new source package to have libselinux1 remain in the archive, and
go from there.
I see no need to behave differently if my package is coded in
Python rather than in C. So create python-foo2, or python-foo1, in a
fashion equivalent to what we do when the soname for a C lib
changes. But until there is a backwards incompatible change, there is
no need to do anything special (like changing the control file).
Now, if the default version of Python in stable is dropped
from testing, then there is an issue with partial upgrades from
stable to testing ONLY for packages that have DELIBERATELY broken
compatibility with the default version in stable.
I would say we admonish people not to break compatibility with
any version of Python shipping in the next release, and also not drop
the default version in stable from testing. With these two policy
directives, the partial upgrade issue is mitigated, and I think these
are reasonable policy decisions.
Even if upstream uses new features from the new version of the
language (like decorators in version 2,4), the maintainer can still
keep the old version around, create a wrapper, and conditionally load
the old or the new version depending on the version of python used.
I am willing to make life harder for people who introduce backwards
incompatibilities in a pure python module when not doing so is simple
workaround of conditional inclusion allows you to work with the old
as well as the new python version. Debian maintainers are supposed
to be competent enough in the languages used in the packages they
maintainer to do a simple little extract into private module, and
conditionally include one set of code or the other.
On the issue of provides: I hate the notion that provides may
be required, but hold on until someone asks for it bit. Either
provides should be there, or not. If provides are required, then I
support any private packages my users build as well as the so called
"official" repo -- and since I have no way of knowing what private
module packages out there are using, either provides become
mandatory, or are not required. We are building a community her, not
a club for DD's, so user created Python modules should not be
neglected.
It has been brought to my attention that a conservative
maintainer might wish to assume that his module is incompatible with
any older python versions that he hasn't explicitly tested it with,
as well as any future versions of Python, because knowing that the
code works correctly with an older version is a non-trivial
problem. In this case, the conservative maintainer would never use
XS-Python-Version: all, and the rules for pure python modules with a
subset of versions of Python supported already have provisions for
provide. So what's the conservative maintainer to do when adopting a
package from a liberal one?
Well, the conservative maintainer has a hard row to hoe: talk
to the rdepending package maintainers, ship the modules for all
possible versions, including oldones, even when upstream changes
code, and do a mini transition with all rdepends, write stuff in
NEWS.Debian, and do the mini transition dance. As long as all
officially supported versions are still supported, and the package
does the provides bit, then things are fine.
Also, there is another problem with unneeded provides:
Suppose I have an extension module foo that depends on pure python
module bar. If bar only supports a subset of the Python versions,
then I can't just use XS-Python-Version: all either, and determine at
build time which version of python to compile my extension for. The
current state of the provides lines for bar in the archive determines
which modules I ship, and if the state of bar ever changes, I need to
react to the changes in the provides line, and recompile and
re-upload.
This means that when new versions of python come out we can't
just do a binNMU; the control file must change too. I think provides
complicate the packaging of rdepends enough that unnecessary
provides, added just to appease the case of partial upgrades to
packages that have delibrately chosen to break backwards
compatibility from versions currently shipping in testing, are
untenable.
My understanding is that a major goal was to automate the
process of supporting new versions of python as they were added to
the archive, and automatic bytecompilation being all that is required
is an important enough goal that I am willing to give on partial
upgrades for packages that delibrately have broken compatibility, and
have elected not to change names like we do for C libs
manoj
--
The Osmonds! You are all Osmonds!! Throwing up on a freeway at
dawn!!!
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: