Hi, On Sun, 04 Jun 2006, Joe Wreschnig wrote: > On Sun, 2006-06-04 at 20:56 +0200, Raphael Hertzog wrote: > > Hello, > > > > 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?
For extensions they are required. For arch:all modules they're not required since python-support / python-central can make them instantly available to a new python version. > - 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. There's only python2.X-* _virtual_ packages. They are desirable but not needed unless a python application which doesn't use the default python version requires a specific python-version of a module. However I don't see the problem of providing systematically python2.X-foo (in particular for extensions). > Until these two issues are clear, everything else is irrelevant. The > goal shouldn't be to pick a tool, but to solve the problem. If neither Which problem? > > 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. Yes there was a clear consenus on that point. It's the only way to have sane inter-dependencies between modules and extensions because otherwise modules depending on extensions do not know which package they need to depend on since it really depends on the running version of python. 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]
