On Sun, Jun 04, 2006 at 07:16:14PM +0200, Marc Dequènes wrote: > >> Let me reexplain the situation i was talking about with a little graph: > >> python-editobj (using python-support) > >> | > >> python2.3-soya (compiled) > >> | > >> python-ontopofsoya (using python-support) > >> | > >> slune (using current version) > > A package named python-ontopofsoya should not be depending on just > > python2.3-soya. It should be depending on python-soya, which can depend on > > (or provide) python2.3-soya. > You're right, i made a hasty shortcut. > > *IFF* python-ontopofsoya Provides: python2.3-ontopofsoya, then it must also > > depend on python2.3-soya. If it Provides: python2.4-ontopofsoya, then it > > must depend on python2.4-soya. But this is merely an expression of > > existing/previous python policy using virtual packages. > >> In this example python2.3-soya is required because the slune depends > >> on the python package and the current version is 2.3. But since slune > >> does not directly depend on soya, and should be unaware of the > >> ontopofsoya backend (could possibly use pyopengl for example), and > >> python-ontopofsoya cannot arbitrarily choose a soya version, or would > >> choose the default one. > > python-ontopofsoya *must* depend on python-soya, which must exist as either > > a virtual or real package. The python-ontopofsoya and python-soya packages > > must also be available in forms that work with the same version of python, > > or else python-ontopofsoya is uninstallable (a feature, not a bug). > > Likewise, if python-ontopofsoya Provides: python2.3-ontopofsoya, > > python2.4-ontopofsoya, then it must also depend on the packages it needs for > > *each* version of python it declares support for in order to be useful with > > that version. > I do agree in the form, but: > 1) this is quite a mess of Provides and Depends. Yes it can be > generated by tools, but this seems quite ugly, and would surely slow > down apt logic more and more. I didn't claim that it was pretty, but it is the minimal solution to properly support packages in this configuration. It's also no *more* complex than the current situation with having separate real packages. > 2) this solution mean either you need to depends on all versions of > dependencies you need, resulting in depending on all python versions > in the end, or to introduce plenty of dummy packages, which is clearly > what we wanted to avoid, even if it can also be generated. Moreover, > going through NEW for new versions is a lot a load for ftpmasters > which is absolutely unnecessary. Dummy packages can't be done automatically; if you have to add additional real packages, dummy or not, that's going to require sourceful uploads for editing debian/control, so that's something to avoid if at all possible. > After discussing with buxy, it seems it was discussed in DebConf (while > there is no real report about this on this list), and having all > versions included in the same package was the selected solution to avoid > dependency nightmares. Unfortunately, I don't know that anyone was taking notes at the python BoF, we were a bit busy running around and discussing; I was hoping that the videos would be on-line sooner than they apparently will be. -- 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