Coin, Steve Langasek <vorlon@debian.org> writes: >> 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. 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. 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. Buxy also told me Joss finaly accepted this solution while he was clearly against pycentral, so i'd like to have his word on the subject, but he is unresponsive and seems to have lost any motivation on this project... :-( -- Marc Dequènes (Duck)
Attachment:
pgp3c0YI_RaiU.pgp
Description: PGP signature