On Thu, Jan 26, 2006 at 03:26:25PM +0100, Matthias Klose wrote: > While preparing some example packages to experiment with > python-central and python-support, I did see some issues with both > proposals, in that the dependencies are not fulfilled for every python > version that both packaging systems claim to support. Feedback is > welcome.
> For an example see python-pmw (only one binary-all package with the > same name is built by the source package): > Package: python-pmw > Depends: python-tk, python (>= 2.3), python (<< 2.4) > which, when packaged with one of the packaging systems, becomes: > Package: python-pmw > Depends: python-tk, python (>= 2.3) > Trying to use python-pmw with a python version, which is not the > default, will fail, if the pythonX.Y-tk package is not installed for > that version. To generalize, every binary-all python library package > depending on a binary-arch package (containing an extension module) > does have this problem. > Looking at an application using python-pmw (i.e. pymol): > Package: pymol > Depends: python (>= 2.3), python-pmw > The package will still work after an upgrade of the default python > version. Assuming that an application package uses a specific python > version, i.e.: > Depends: ${python:Depends}, python-pmw > --> > Depends: python2.3, python-pmw I think this is going to invariably be the wrong thing to do, just as it is today. If a package Depends: python2.3, it should also Depend: python2.3-pmw, not python-pmw. I really don't see any other way to ensure consistent dependencies except not *providing* a python2.3 package, which would seem to be even less satisfactory a solution in the general case. So if python-pmw is intended to contain the bits that make pmw available to python2.3, it must Provide: python2.3-pmw. When the python-pmw package ceases to support python2.3, it should drop the Provides; then dpkg will refuse to upgrade python-pmw without removing the application, which is the situation we want. > the package dependencies may not be fulfilled anymore. That could be > solved by adding to python:Depends python2.3-tk. Either the package > maintainer has to do that explicitely, or dh_python has to find these. Is dh_python going to find these goodies for us in other cases? Sorry, I've never used dh_python. > The issues (and questions) are: > - The packaging infrastructure forces the installation of the default > python version, it's not possible to install a non-default version on > it's own (if at least one package using the infrastructure is > installed). > At least thats one thing I can live with; others as well? Yep, I think that's a reasonable requirement. > - As outlined above, we cannot enforce correct dependencies with the > proposed packaging infrastructure (both variants). That is only the > case when using a non-default python version. AFAICS this would > violate the Debian policy. Should there be an exception? No; see above comments. > - A packaging infrastructure not supporting binary-arch modules > covers about 50 out of 200 source packages providing python modules > and extensions (that number may not be accurate, just counting > packages using the python- and pythonX.Y- prefixes). > That number can be raised, if extension modules for all supported > python versions are made available in one package (at least for the > version we transition from and for the version we transition to). > This approach has it's limitations, i.e. python2.3-tk and > python2.4-tk are built from separate sources and cannot be put in > one binary package. It does help for packages like zopeinterface > and twisted, where only very small extension modules are put in > one package supporting more than one python version. Even larger > extension modules could be packages this way for at least the > time of a python transition to support both old and new version (a > package like pygtk2 comes to mind, having many rdepends). > We still do have the limitation, that every python module depending > on a pythonX.Y-foo binary-arch package cannot use the packaging > infrastructure. Two comments here. First, I don't think all python extensions *should* be packaged in a single binary package for all versions; I seem to recall the Ubuntu wiki page on the topic conceded this point. Second, I don't think that there's any a priori reason why the python packaging infrastructure cannot or should not cope with splitting binaries up into python2.x-foo packages, in an automated fashion. Given that this is something we're likely to want to support for a while, then, I think it would be better if efforts were focused first on making this happen, and later sorting out the merging of binary extensions into a single package. > - AFAICS the proposed packaging infrastructure doesn't help the > migration of a new python default version to testing much. It does > help maintainers of these 50 source packages, but still requires > uploads of the other 150 packages (potentially introducing > dependencies on newly uploaded libs). Supporting more than one > python version for binary-arch packages does raise that number. Yes, that's a fair point. But by now, I think more time has been spent talking about how to improve things, and/or waiting for an implementation to happen, than the entire python2.4 transition should have taken. :) Even having 1/4 fewer packages that need to be managed in the transition will surely be of help. Having binNMUable, all-in-one binary packages for python extensions would be icing on the cake -- it's certainly far more ambitious than anything I initially had in mind when starting to poke at python policy. So at this point, I would be inclined to suggest that the byte-compiling stuff be implemented as a first pass, then we can start the python2.4 transition with what we have, and the Magic Dancing Python Extensions<tm> can be figured out in parallel to this. > - Just another proposal could be to keep the package structure > python-foo, python2.3-foo, python2.4-foo, put all arch independent > files into python-foo, using the proposed python infratstructure > to promote the packages to each python version and putting > extension modules into the pythonX.Y packages. In case of > binary-all modules, the pythonX.Y packages are just dependency > packages. > That proposal does address the concern of putting the source in > only one package, avoiding code dubplication in binary packages, > but still requires new upload of the package for a python > transition, not supporting a migration to testing very well. > There are some packages using such kind of setup. I don't think we need to avoid *all* reuploads of packages during a transition. Anyway, I guess this is largely equivalent to what I suggested above (allowing both the existing approach to binary extensions, and your enhanced automation). > Can we neglect the dependency issues for modules available for > non-default python versions, seeing these just as an aid for doing a > transition and require packages explicitely using a non-default > version to add these dependencies themself? If you mean, not provide automation for such packages, that seems like a reasonable approach until someone demands support for it and/or provides a patch. :) Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/
signature.asc
Description: Digital signature