[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 is fully supported in Debian now. I (as a package maintainer) want it to be (byte-)compiled for all supported Python versions. It's arch:all so when new (2.5, 2.6, ...) Python version will be added to the supported ones or user will install unsupported Python version (that still matches versions specified in package's Python-Version header) I want python-<system> to byte-compile it for all installed Python versions that my package can work with. I think it's dh_tool task to set Python-Version field correctly (by parsing build dependencies and XS-P-V / pyversions) so that python-<system> and RMs will not have problems with telling (grep-dctrl): * which packages will need binNMU when list of supported Python version will change (public python extensions) * which packages will need binNMU when default Python version will change (shebang issue, private python extensions) * which packages will only need byte-compilation for newly added Python versions (or removal of old .pyc files) * which packages will only need recompilation of .pyc files (private modules, public modules used only by Python applications ["current" keyword]) If dh_tool will set Python-Version header in binary package and it's (Python-Version's) content will be standardised as well as the location where python-<system> should look for .py/.so files, I think we can just set Depend: to python-system where python-system is provided by python-central or python-support (no need to install both systems) > 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 * 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 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) [1] at user's machine (when new version of "python" package will be installed) > 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. -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=-
pgpcG4pKkUDFa.pgp
Description: PGP signature
