Re: Updated python-support
On Sun, 18 Jun 2006, Josselin Mouette wrote:
> * Automatic dependency generation in dh_pysupport, removing the
> need to run dh_python.
It's not only removing the need to run dh_python, it requires the
maintainer to remove dh_python because both are not coexisting nicely
any more. They are doing the same work in a different way and we get as
result a mix of dependencies generated by each of them.
This sucks because:
- you didn't voice any concern when I worked on dh_python
- you have let me NMU debhelper for that dh_python and then you work
against it
And we have been advising to use dh_pysupport WITH dh_python since the
beginning of this transition.
See below for an in-depth analysis of the situation and a suggestion on
how to go forward.
> The last change is a source of strong disagreement between Raphaël and
> myself. Having seen the result of messing up with dpkg's database and
> control fields [0,1], I don't want to use the XS-Python-Version field,
> and I've done things the Debian way, with a debian/package.pyversions
> file, like helper scripts have always done.
>
> (No, this specific point doesn't conform to the new python policy, but
> this policy is only a draft and I don't see a reason to stick to it
> while it hasn't been widely implemented, especially when there are
> better solutions.)
The new policy was consensual until now, even if people (you included) had
made concessions so that we can go forward.
By refusing to rely on that field (and not putting it in your packages),
the following things change:
- the Python-Version field will be useless to accurately track which
packages need to be updated
- from a Policy-mandated field it becomes now a python-central
field (since the python policy has no official weight yet, we can only
go forward with a broad consensus)
This has several consequences on dh_python.
Right now, the constraint on dh_python is that it must generate the
right dependencies in a "mostly-agnostic" manner. It generally does that
however we have two problems now:
- dh_python uses the XS-Python-Version field to decide to run in "new
policy" mode. If some packages do not follow that, we'll be in
troubles.
- since most "arch: all" packages do not require a re-build for a new
python version they get by default a "python" dependency. This is
suboptimal since modules often require a specific python version (say
they work with any python >= 2.3). So that dh_python can generate the
right dependency, it extracted minimum/maximum versions from XS-P-V.
Now python-support uses something else for that
(debian/package.pyversions). If I want to support both tools, I fail
the rule to be "mostly-agnostic".
We have two scenarios:
1/ If we accept dh_pysupport as is, dh_python "new policy" is only useful with
dh_pycentral and packages using that XS-P-V field. => we can as well stop using
dh_python new policy and merge back stuff into dh_pycentral
2/ We work to make dh_pysupport and dh_python collaborate nicely again
given the 2 new constraints above. That's my preferred scenario because:
- dh_python is way smarter than dh_pysupport for generating the right
dependencies
- it doesn't break packages which we have already updated
- it separates cleanly things which depend from the helper from
those that are common to all python packages
Here are the changes that could be done to resolve the dh_python problems:
- we follow Pierre Habouzit's suggestion to introduce
"XS-Python-Standards-Version: 0.4" field for any package using
the new policy. This is the trigger for dh_python to decide how it will
work (old policy/new policy).
During an interim period, dh_python would also work without that field
but with XS-Python-Version.
- the second problem is more difficult. The meta-information have to come
from somewhere, I can't invent it. The maintainer has to provide it to
the script. dh_python being a debhelper script, the official way for the
maintainer to provide infos to a debhelper script is either the command
line or a debian/package.something file.
I could invent a dh_python specific thing but since Joss is already gone
down that path, I can as well reuse his work on that point (the
debian/package.pyversions format is easy to deal with, easier than the
XS-P-V format).
Drawbacks:
- without changes, python-central won't generate fine-grained python
dependencies anymore... to circumvent that dh_pycentral would have to be
modified to generate the debian/package.pyversions file from the
XS-Python-Version field.
Advantages:
- everybody is semi-happy and we can continue this transition without
loosing the progress we already made
Ok, here you have a clear picture of the situation today and a suggestion
on how to go forward. Comments are welcome of course.
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
Reply to: