On Thu, Dec 10, 2009, Josselin Mouette wrote: > Rationale: let’s consider a package foo that uses python2.4 directly > (with a python2.4 shebang), and depends on python2.4-foo, provided by > python-foo, which in turn depends on python-bar. If python-bar is > rebuilt with XS-P-V: >= 2.5, it will stop providing python2.4-bar, but > python-foo will not change, and will still provide python2.4-foo. Then > foo will simply stop working. > > This is why the usage of pythonX.Y-foo dependencies should not be > recommended. Packages providing public modules should all be in one of > these cases: > * No Provides: ${python:Provides} at all. > * The package has no dependency on other Python modules. > * The package depends on all pythonX.Y-bar, for X.Y in > ${python:Versions} and bar in all dependencies in other modules. > > Since the last solution is very suboptimal (it requires simultaneous > uploads and testing migration for all entangled packages), it should be > avoided – and anyway we should discourage use of a specific pythonX.Y > version.
I agree that in general we want to avoid using a specific pythonX.Y version in packages. I also agree that there is a problem with the current situation which doesn't ensure that pythonX.Y-foo really works when bar changes. It would be ok to not have Provides: in python-foo when there is no reverse dependency requiring a non-default python version. It makes it harder to have a package depend on a non-default version of python-foo, but this has to be balanced with requiring pythonX.Y-foo -> pythonX.Y-bar for all versions. An entirely different approach is simply enforcing that at in transitions or at the QA level: * either ensure that we do rebuilds in the proper order when the list of suppored version changes (rebuild python-foo before python-bar) * or simply have a debcheck-alike script which verifies that there is no case of a pythonX.Y-foo dep where pythonX.Y-bar is missing Another approach I can think of is to put the burden on the package requiring a specific python version: * either manage the recursive pythonX.Y-foo and pythonX.Y-bar deps manually in the package * or require installation of python-foo when this package gets built as to allow computing its recursive dependencies I don't quite like the latter, as it pulls more stuff than needed at build time and is a bit fragile, but it does shift the problem on a much smaller subset of packages, and doesn't prevent the rest of the python packages to move on. > Another related issue is that of packages linking to libpython to embed > an interpreter. Most of them link to the library corresponding to the > default python version of the moment. Therefore all their dependencies > should be pythonX.Y-foo and not python-foo like what is (incorrectly) > done currently. I aboslutely agree that these should depend on pythonX.Y for libpython itself; it might make sense to expand their python-baz (>= x) deps to python2.x-baz, python2.y-baz, python-baz (>= x), but it's not clear how to express that the package will use this or that version of python at run time. For extensions, it might make sense to require all versions of all depended upon packages. But I'm very worried that any such change will tighten deps a lot, while we might be able to simply catch these with more QA / cleaner transitions. One similar issue in Debian I have in mind is when we have two versions of a library, and a complex set of dependencies load them together in memory; we want to avoid this, but it's not easy to enforce via deps. -- Loïc Minier -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org