On Sun, Jun 04, 2006 at 03:44:03PM -0500, Joe Wreschnig wrote: > On Sun, 2006-06-04 at 20:56 +0200, Raphael Hertzog wrote: > > now you know a bit better the policy (or at least the generic idea, feel > > free to discuss details further), > No. After the previous thread I am still in the dark on: > - Tight upper dependencies. We you just incorrect, or are they > actually required? > - python2.x-* packages -- are they needed? desirable? > Steve and Matthias gave different answers, and if they're present > migrations end up just as fragile as they are now. No, not as fragile. Even in the worst case here, the ability to rebuild for new (or for dropping old) versions of python via simple binNMUs gives us a good deal more flexibility. > > 2/ Extensions can't be shared between several python versions so they need to > > be compiled once for each. The packaging needs to be modified to do those > > compilations. We really need a tool (maybe dh_python with a special flag) > > to generate dynamically the list of python version that the package must > > be compiled with. The .so files must be installed in /usr/lib/python2.X/ > > and the associated .py files may be moved to a shared directory (either > > the python-support or python-central directory). > Was there consensus about whether or not extensions for all versions > should be included in one binary package? This was not mentioned in your > policy email. I'm ambivalent on the issue, I guess, but we should choose > one way or the other. I don't recall this being a point of contention at the BoF, which perhaps implies that there is a consensus. :) Most of the discussion did assume we were trying to solve the problem of making python extension packages binNMUable for transitions, and this means putting the extensions into a single package so that we don't have changes to make to the sourceful debian/control when rebuilding, nor going through the NEW queue (or needing older binary packages to be dak rm'ed). > This IMO is the most important part. It's here, and we're using it. > python-central has "right arond the corner" for months. Many modules are > already using -support, and it integrates very easily with any project > using distutils. With proper debhelper integration it would be even > simpler. At this point, with no small portion of the blame on my shoulders, we're way behind the agreed-upon deadline to have a working dh_python / python-central solution in unstable, and we do need to get the python2.4 transition started with or without this aid. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. vorlon@debian.org http://www.debian.org/
Attachment:
signature.asc
Description: Digital signature