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. 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. 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. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `- our own. Resistance is futile.
Attachment:
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=