Recursive dependencies on pythonX.Y-foo practices

[Loïc Minier <lool@dooz.org>]

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