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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
