On Thu, Mar 22, 2007 at 10:13:40PM +0100, Piotr Ożarowski wrote: > [Josselin Mouette, 22.03.2007] > > Le jeudi 22 mars 2007 à 19:56 +0100, Pierre Habouzit a écrit : > > > > Just nitpicking: the dh_ tool doesn't need to know that, as it can guess > > > > it from what was previously built. This is a hint for the release > > > > managers (to know which packages need a binNMU), and could be the base > > > > for a script automating the build process. > > > > > > It's not necessarily true: when there is only one python supported, > > > you can't tell the difference between a package that only supports the > > > default python, or any of them :) > > > > This is not a problem for the dh_ tool, as the resulting binary package > > will be exactly the same in both cases. > > simplejson package is build only for python2.4, because only this version That's a pure python module, that scope of the policy is well understood, and works without anybody's help thanks to the dh_tools. There is no human help needed for that, at all. > > This is indeed a problem for the release managers, as they need a way to > > disambiguate between these two cases. In this case, "current" is a hint, > > a declaration that has to be matched by what's in debian/rules, but it's > > not a proof the package is built this way. > > > > If we really need such a hint, I'd prefer to see it in another place > > than the field containing version information. However we might as well > > use the python-dev / python-all-dev build-dependencies to obtain the > > same information. > > python-dev / python-all-dev issue should be (IMHO, of course) used just > at the build time to set Python-Version correctly. python-system should > not depend on informations from source packages (it simply doesn't have > access to them). Python-Version (or whatever we will call it) should > contain informations about: > > * which Python versions this package can work with that's not doable. The PV field or its equivalent debian/pyversions has to be filled. There is no way for the build system to know if this or that extension is compatible with this or that python version. This is a declaration that the maintainer has to do. This information is only useful for the dh_tool though, so I don't see the need to make it mandatory. It's up to the maintainer to choose what fits his needs. What has to be mandatory is the annotations that other python packages needs (the Python-Provides proposal), and what the RM need (and here PV is only part of the things the RM need). > * is this package meant to be compiled for all allowed Python versions or > just for a single (default or nearest available) version > * and maybe: does this package has a shebang to handle that is the maintainer's job and maybe the dh_tool one to deal with that. > If the second, python-system can check [1] if it can/should change shebangs > automatically (if package is arch:all and default Python version meets > requirements) No he should not. At least not automatically. In fact, when the package is pure python, that already works automatically. I don't really think you grasp the issues we were discussing. The "issues" you raise are already dealt with and correctly understood. Though the policy is really badly written if it wasn't already obvious to you (and I do thing it is, badly written I mean). > > I don't think we are missing any case, but we should probably write some > > binNMU detection script for use by the release managers, summarizing all > > of these thoughts. > > It should be really easy if all Python-related packages will have > Python-Version field. No, honnestly I don't think you get it correctly, but I may be mistaken. Though I think one of my mail already explains the whole thing pretty clearly. -- ·O· Pierre Habouzit ··O madcoder@debian.org OOO http://www.madism.org
Attachment:
pgphqM99er8q9.pgp
Description: PGP signature