[gentoo-portage-dev] RFC: {ex,im}porting runtime deps

[Thomas de Grenier de Latour <degrenier@easyconnect.fr>]

Hi,

In some overlay ebuilds i'm maintaining for an OCaml software
("Demexp", see http://tdegreni.free.fr/demexp if you're curious,
but we don't really care for this discussion), i'm facing the
following issue:
 - pkgA DEPENDs on pkgB, but does not technically RDEPENDs on it
 - pkgB have some USE flags to trigger optionnal use of some libs
 - pkgA will be linked to the libs used by pkgB
So, the problem is to get accurate RDEPEND for pkgA: it should
not include pkgB, but should take pkgB's USE flags, and thus the
deps they introduce, into account.

One possible (future) solution would be eradicator's GLEP about
binary deps. RDEPEND would stay incomplete, but "soname.DEPEND"
would keep track of what is missing, and thus it would in theory
be possible to do a depclean without breaking pkgA.

But before i realised that his proposal was actually covering this
case, i've been thinking of a different approach which might be
interesting too. 


{EX,IM}PORT_RDEPEND:
====================

Example, with the above pkgA/pkgB case:

=== pkgB.ebuild: ===
DEPEND="...whatever1...
        flagX? ( libX )
        flagY? ( libY )"
RDEPEND="...whatever2..."
EXPORT_RDEPEND="flagX? ( libX )
                flagY? ( libY )"

=== pkgA.ebuild: ===
DEPEND="...whatever3...
        pkgB"
RDEPEND="...whatever4..."
IMPORT_RDEPEND="pkgB"

The semantics of the above is pretty obvious: it would mean that
pkgA's RDEPEND should be augmented with whatever pkgB has
exported (depending on the USE flags pkgB is built with, could be
either none, libX, libY, or both libX and libY). But pkgB itself
would not become an rdep of pkgA.

>From a syntactic pov, IMPORT_RDEPEND and EXPORT_RDEPEND are
usual depstrings. 

>From a deps resolution algorithm pov, the (simplified) idea would
be something like that:
 - pkgA's IMPORT_RDEPEND is evaluated into a list of cat/pkg-ver
with the existing algorithm. Here, it becomes "pkgB-1.0" for
instance.
 - we then need the reduced version of the EXPORT_RDEPEND of each
of this packages: 
    - if pkgB-1.0 is a new package to be compiled, then its
      EXPORT_RDEPEND is reduced for whatever USE flags it will
      be compiled with.
    - if pkgB-1.0 is already installed, then its already reduced
      EXPORT_RDEPEND is read from the vardb.
    - same if pkgB is a binary package to be installed, get it
      from its metadatas.
 - this reduced EXPORT_DEPENDs are added to pkgA RDEPEND, and
resolution continue the normal way.


Use cases:
==========

Sure, it would be exactly what i need in the case of my demexp
ebuilds, but it could have many other uses too. In particular,
it's an other way to solve the "binary deps are be more precise
than compile deps" issue:

 - if "somelib-0.9.7" is incompatible with "somelib-0.9.8", but
some package "foo/bar" can be compiled for any >=0.9.7 versions,
we could have something like this:
=== somelib-0.9.7.x.ebuild: ===
EXPORT_RDEPEND="=somelib-0.9.7*"
=== somelib-0.9.8.y.ebuild: ===
EXPORT_RDEPEND="=somelib-0.9.8*"
=== foo/bar.ebuild: ===
DEPEND=">=somelib-0.9.7"
IMPORT_RDEPEND=">=somelib-0.9.7"
And then a "foo/bar" binary package would have an accurate RDEPEND
on "somelib", depending on what version it was compiled against.

Note that this case would also be handled fine by eradicator's
GLEP. At the contrary, the following would not i think (also
last discussion here about this GLEP is a bit old, so maybe it
has been extended since):

 - dev-python/somemodule depends on >=python-2.2, but once
compiled/installed, it actually depends on the python version it
was installed for. Solution: add an EXPORT_RDEPEND="=python-2.X*"
to python-2.X ebuilds, and an IMPORT_RDEPEND=">=python-2.2" to
the module ebuild. Same for perl modules, ocaml modules (which
are even more picky on the versionning), etc. 

 - programs/libs which do some dlopen("libfoo.so.X.Y") would not
play nicely with automatic .so deps detection.  At the contrary,
the export/import mechanism is declarative and thus allow you to
state whatever is needed to get accurate runtime deps, provided
you've greped the code to find its dlopen calls.

 - in conjonction with the future "built with USE" depend atoms,
it could be used to stick some flags in RDEPENDS. For instance,
"foo/bar" depends on wxGTK, which can be built with or without
unicode support. "foo/bar" really doesn't care about unicode, but
once built against on or the other flavor of wxwidgets, it can run
only with that flavor. Then we could imagine having:
EXPORT_RDEPEND="unicode? ( x11-libs/wxGTK:unicode )
               !unicode? ( x11-libs/wxGTK:!unicode )"
(or whatever syntax it will be) in wxGTK.ebuild, and an import in
foo/bar.ebuild.


Open questions:
===============

Well, there are many open questions left, like:
 - how could it be made transitive? (ie., how to re-export some
imported deps)
 - should IMPORT_RDEPEND get a default value from (R)DEPEND? (in
the cases i've thought about so far, each time an ebuild depends
on something, it also wants its exported deps if any)
 - etc.
But the most important one is: does it worth thinking more
seriously about it or is this too complicated / useless / ...?
Comments welcome. 


Thanks,

-- 
TGL.

-- 
gentoo-portage-dev@gentoo.org mailing list