Le dimanche 18 juin 2006 à 23:12 +0200, Raphael Hertzog a écrit : > 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
For that, I have to be sorry. I didn't have enough time to work on Debian at that moment, and realized later the python transition was going to a dead end, when I read many complaints from skilled developers telling me they didn't even understand what the "new policy" was about. > The new policy was consensual until now, even if people (you included) had > made concessions so that we can go forward. And these concessions only lead to a broken design. I want to step back on the unnecessary things so that we get a comprehensible and robust python build system as soon as possible. > - the Python-Version field will be useless to accurately track which > packages need to be updated Is it really useful? (This is a real question.) Isn't it possible to follow it just as easily with a script, avoiding to put cruft where it doesn't belong? > - 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) I think you are exaggerating the importance of the policy. A policy in Debian becomes effective when most packages use it. This is even true for the Policy with a big P. > - 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". This is one of the reasons to make dh_pysupport work without dh_python. > 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 This is true, but I'm working on it. The important part is the missing ability to handle packages providing (private or public) modules only for non-default python versions - which will obviously be the last packages to migrate to the new packaging scheme, as they simply don't need it. I know how to improve that, but I'm wondering whether it's worth the deal, as these packages don't need any functional changes from the "old policy". Why having them depend on a tool when a few lines in the postinst/prerm are enough? > - 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, I have to disagree. The dependency generation for python-support strongly depends on python-support itself. It relies on .version files for modules, and on directories in /usr/lib/python-support for extensions. This is not agnostic. > 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). This is way too complicated. I'm trying to make things simpler, please don't make it useless by adding new fields. Let's discuss how to improve the solution by improving the tools before adding new policies and bureaucracy. > Ok, here you have a clear picture of the situation today and a suggestion > on how to go forward. Comments are welcome of course. I think having dh_python as a common place to generate dependencies is a good idea, as some of the logic is the same in both tools. I also think it's still possible for it to be this place. I haven't uploaded python-support 0.3 yet so that we can go on working on it. It may turn out to be too difficult, but it's worth a try. However, I don't think you can keep dh_python independent from pycentral and python-support. The XS-Python-Version field was a pycentral-specific field from the very beginning, and python-support simply uses a different versioning scheme. -- .''`. Josselin Mouette /\./\ : :' : [EMAIL PROTECTED] `. `' [EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
signature.asc
Description: Ceci est une partie de message numériquement signée
