On Wed, Jan 18, 2006 at 01:06:39PM +0100, Matthias Klose wrote: > Josselin Mouette writes: > > Le lundi 16 janvier 2006 à 15:24 +0100, Matthias Klose a écrit : > > > This is the right direction, and adding support for extensions makes > > > this complete. Does your proposal allow rebuilding these packages > > > without actually changing anything (except the changelog). > > Being able to rebuild packages for a new python version without changing > > anything was the purpose of dh_python from the very beginning, for both > > packaging styles: > > * for packages with a single python-foo package containing > > extension foo, build-depending on python-dev, a rebuild will > > generate a new package built against the new version; > > * for packages with python2.3-foo and python2.4-foo, a rebuild > > will make python-foo depend on the new version. The only case > > that isn't handled is when the package isn't maintained much, > > and lacks python2.5-foo when the python2.5 transition > > approaches. > > This is independent of python-support. > the design decision of putting the binary-all python packages in a > separate directory into /var/lib/python2.x/site-packages has some > problems when supporting packages with extensions (a proposal beeing > made on #irc was to keep the extensions in the standard path). > suppose you have the following scenario > /usr/lib/python2.3/site-packages/foo/ > __init__.py > fooext.so (doing a "import foomod") > foomod.py > which is splitted into (by python-support) > /usr/lib/python2.3/site-packages/foo/ > __init__.py > fooext.so > /var/lib/python2.3/site-packages/foo/ > __init__.py > foomod.py > Having /var/lib/python2.3/site-packages appended to sys.path let's the > import of foomod fail (cannot be found). Using just one package > directory inside /usr/lib/python2.3/site-packages does avoid the > problem (the way the current python-central works). I think this objection is misguided for the following reason. If a package includes a python extension, then any .py files it also includes are either in the same directory (or same tree) with those .so files, or they are in some other unrelated directory. If they are in the same directory, then *that directory has the name of the python implementation in its path*, because .so's are not shared between python implementations. In this case, it is not appropriate or reasonable for these .py files to be managed via a symlink farm, because each minor version of python has its own separate .py file (which may not vary from release to release, but that's beside the point). If they are in different directories, then foomod.py already doesn't enjoy a privileged location in the current path; so whether they are symlink-farmed or not, there must already be handling in place to locate foomod.py, so it doesn't much matter which particular directory it's located in. Perhaps you are arguing that a package should be able to ship /usr/lib/python2.3/site-packages/foo/fooext.so and /usr/lib/python/site-packages/foo/foomod.py, and have the infrastructure make foomod.py (or foomod.pyc?) available in /usr/lib/python2.3/site-packages/foo. I'm not sure why this would be advantageous? > So how does python-support handle packages, where the extension > module is split out in it's own binary package? If they're split out in separate binary packages, then surely the extension package doesn't require any special handling, and the module package can be managed as before? (since obviously it's not sensible to split /usr/lib/python2.3/site-packages/foo between two separate packages...) Also, if you really put all of these files in /usr/lib/python2.3/site-packages, doesn't that make it unnecessarily difficult to distinguish between symlinks managed by python-support, and symlinks managed by the packaging system? (I remember that Joss's description of python-support provided for symlinking of other data files that may be included in module directories, other than .py files...) -- 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