Steve Langasek <vorlon@debian.org> writes: > Wow, what a constructive response. You've surely been on this list for > years and must know all the changes that need to be made to Debian's python > policy. Why didn't you reply to Bruce's original question with your own > superior write-up of this policy? Seems evidence that teamwork with you is > impossible. Seems an evidence you don't know anything about me. My work in the GNOME Team *was* appreciated, and AFAIK my work in other teams is too. I recently tested python-support and helped Joss find out problems. Now the latest version is working nicely. This is not a big change, only a minor contribution, but i don't pretend to write a complete perfect policy as you claim. I just don't see any point for discussing such things without involved people. I do ask Joss, Buxy, or any other experimented persons when i need help on Python, not Release Team or X Strike Force people, obviously. For people insterested in python-support related topics, i migrated several of my packages to it with success (namely Slune/Balazar dependencies). Only a minor bug for "-x.y" versions was left (and fixed recently in 2.2). Some of my packages are blocked into NEW, but editobj is a good example for working packaging. Only the .version file has to be made by hand until dh_python is able to do so, which is not a big job. I wonder how some situations (if existing) may be solved as long as we have unique non-versioned scripts-only packages and compiled modules cohabiting. When for eg python2.4-soya needs editobj, it just depends on python-editobj which provides all versions (so the needed version too), and slune ask for a specific soya version depending on the current Python version, that's easy. Now if i make a library based on soya, using python-support, which would be used between slune and soya, there would be no way to specify from slune through the new library which soya version is needed. So, if my reasoning is correct, until compiled modules are all packaged with every version grouped in the same package (like suggested by doko) or we find another solution, mixing python-support packages and compiled modules could be a problem. -- Marc Dequènes (Duck)
Attachment:
pgpzPg4PQyjCZ.pgp
Description: PGP signature