Hello everybody, as you might have seen on Joey's blog, he expressed some wishes about the future of dh_python: http://kitenet.net/~joey/blog/entry/proposed_transition_plan_for_removal_of_dh_python_from_debhelper.html
As I can understand him, we really should respect his wish. If Matthias agrees, I can extract the "dependency" generation code from dh_python and create a little perl library that would be included in the python package (or python-dev) and that would be used by dh_pysupport and dh_pycentral. I can also prepare patches for dh_pysupport/dh_pycentral. dh_python would be modified to support only v1 mode (with a big deprecation warning) and would be no-op if debian/pycompat was 2 (including the implicit pycompat=2 set if the XS-Python-Version header is here). python-support/central will have to depend on the new debhelper to avoid generating dependencies twice if dh_python is invoked (as is currently the case for most packages). The new debhelper will have to be uploaded together with the new python-support/central to avoid any problem (If it is uploaded before, some packages may not have dependencies at all. If it is uploaded after, python-support/central won't be installable.) As I volunteer(ed) to maintain this part of the code (dependency generation for dh_py*), I suggest to start using the pkg-python project (and its associated SVN repository, or whatever VCS suits you best, Matthias) so that I can directly maintain this part of the code in the package. If you don't have time for the initial import and all, just let me know, I can add myself to the project and setup things for you. Now replying to the problems Joey expects: > dh_pthon supports params for passing additional module directories. > dh_pysupport does too, but it seems that dh_pycentral does not. Need to > check if this means that noone using dh_pycentral can use it with > non-standard directories, so none of them pass directories to dh_python. dh_pycentral scans all the directories by itself so it shouldn't be a problem for byte-compilation. For the dependency generation, we need to be able to know that a .so is a Python extension module and not something else and so we rely on this parameter to know that any .so in the directory is effectively a python extension module. I heard that python-support implemented something else (with objdump) to assert that a .so is a python package. In any case, it would be no problem to add the same parameter to dh_pycentral or to improve the way we detect the python extension module. > dh_python has -V and -X flags that affect its behavior and the other two > programs would not have access to this information. > * I doubt that -X is used widely. Grep. > * -V is a redundant interface, since it does something approximating > what debian/pyversons does. So things should be able to switch to the > other interface, except in edge cases (although IMHO it's not an > appropriate interface for a debhelper program), and for the edge > cases, -V could be added to the other two programs. Exactly, we should get rid of the "-V" parameter completely. -X support has been added during my NMU as it was a wishlist that I found useful (so -X isn't widely used). > It's possible that someone might set dh_python's -n flag but not also > set it on their call to dh_pycentral or dh_pysupport. Can't imagine why > though. I don't see any reason either. No worry here. > Not all packages use the new python policy yet. For example, debconf > doesn't. I'm not sure if that's a bug or not. One alternative would be > reverting dh_python to the pre-NMU version (plus a small shim to make it > a no-op if it detects the new policy), to avoid breaking such packages > until they transition. Indeed, for me it appears unavoidable (cf my suggestion above). And we must also coordinate the upload of the new version of the packages. 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]
