Re: dh_python and python policy analysis
On Sun, Aug 13, 2006 at 07:56:09PM -0500, Manoj Srivastava wrote:
> OK, I see I have to dot the i's and cross the t's for this
> case here. So, here is the scenario: package python-foo packages a
> public pure python module. Package bar imports the module
> foo. Package baz is a package not yet written that would be written
> for Python2.6 that would also need module foo, but only when
> we actually get python2.6. Let us also have a package bar-baz that is
> written for python2.5.
AFAICS you've correctly described the requirements for this scenario, but
this is not the scenario that I've been trying to point out to you.
The scenario where your policy draft fails to cover the needs of an
application is this:
Package python-foo packages a public pure python module. Package bar
imports the module foo, and invokes /usr/bin/python2.3 as the interpreter.
Current is 2.4, 2.3 is still in the archive (naturally, since bar uses it),
other later versions may be available but are irrelevant; for our purposes,
assume that foo is simple enough that it's compatible with all versions of
python, past and present.
Under 4.6 of the draft python policy, python-foo does not declare any
Provides; thus:
Package: python-foo
Version: 1.0-1
Depends: python
Package: bar
Version: 1.0-1
Depends: python2.3, python-foo
This is the only possible expression of these package relationships which
is sanctioned by the policy draft.
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.
Now we have:
Package: python-foo
Version: 2.0-1
Depends: python (>= 2.4)
Provides: python2.4-foo
But this package still satisfies the dependencies of package bar, even
though bar needs python2.3 and python-foo is no longer compatible with
python2.3. The package will be broken on partial upgrade, unless python-foo
also adds a versioned conflict on bar! Thus, the problem arises when
support for old versions of python is dropped by a module, rather than when
new versions of python are introduced.
Versioned conflicts are not scalable, frequently confuse the packaging
system into removing packages instead of upgrading them, and will inevitably
tend to be added after the fact resulting in unnecessarily bad user
experiences in unstable (or even in testing and stable, if they escape
notice long enough). This is why a package which needs module foo to be
available for a specific version of python, instead of for the default
version, should not be allowed to depend on python-foo. It is the same
rationale as for requiring library package names to be changed with changes
to library sonames.
Now, whether python-foo actually declares Provides: python2.3-foo in the
first place is something I think should be left entirely up to the
maintainer; if the maintainer chooses not to declare the provides, then we
should not allow bar to be packaged, because its rightful dependencies are
"python2.3, python2.3-foo" and the latter dependency cannot be satisfied. I
think it's perfectly ok for policy to discourage maintainers from diverging
from the default version of python -- indeed, I think it's ideal to have
only one version of python for a given stable release. But *if* a package
is going to be in the archive which will require a non-default version of
python, I think it's important that it be packaged in a way that doesn't
require retconning with Conflicts to prevent broken package combinations on
a user's system.
> Now we have two policy proposals, A, and B. A decrees that
> python-foo depends on python, ad has no provides. Policy B requires
> that python-foo also provide python2.3-foo and python2.4-foo.
I don't actually think it's a good idea to require python-foo to provide
python2.3-foo and python2.4-foo. I do think it should be *permitted*. I
also recognize that expressing in the python policy when it is or isn't a
good idea to declare the provides would be rather complicated...
Now, looking at your example:
> The following transition events occur.
No disagreements on 1) and 2).
> 3) Python2.3 is dropped.
> policy A policy B
> no upload. Upload python-foo, removing
> provides for 2.3
Why does python-foo need to drop the provides for 2.3? In what way does
python2.3's removal from the archive mean that python-foo has stopped
supporting python2.3?
Now, if python-foo depends on an extension module and declares provides,
then yes, it would need to be reuploaded whenever python2.3-quux ceases to
be available. This will already be true for any modules that don't support
all python versions.
Also,
> 4b) foo can't be written for version 2,6, or will take time, and
> support for 2,6 is dropped (at least for the moment)
> Policy A policy B
> Package uploaded, with provides, Package uploaded, with provides
> Packages bar, bar-baz, and baz Package baz has to wait.
> (rdepends python-foo) informed of
> the provides. Need to upload the
> rdepends
This is a case where I don't see any need to reupload foo under policy B:
it already has all the provides it's going to have, since it didn't yet know
about python2.6 and therefore couldn't have declared any provides for it,
no? So python-foo Provides: python2.5-foo because bar-baz is written for
python2.5 and needs it; bar is AFAICS written to use "python", so only
depends on python-foo; and baz has to wait.
> Even for the case of 4b, there is time to do the transition
> for packages bar and bar-baz -- until 2.6 becomes the default, there
> is no critical bug in bar or bar-baz.
> Now take this to every single pure python module package in
> Debian, multiply with the upload by default for every single
> addition or removal of python packages, and you can see that adding
> more work in the corner case 4b is worth not having to upload
> packages multiple times by default.
Given that a reupload isn't generally needed for 3), and my premise that
pure python modules should only declare Provides when something exists in
the archive which actually *needs* them, I think the uploads between 1) and
4b) would nearly cancel out, making it a win to avoid the need for post hoc
Conflicts.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
vorlon@debian.org http://www.debian.org/
Reply to: