Re: [gentoo-portage-dev] DB and binary dependency

[Brian Harring]

On Thu, Mar 16, 2006 at 02:58:00PM +0100, Paul de Vrieze wrote:
> On Wednesday 15 March 2006 16:13, Gustavo Sverzut Barbieri wrote:
> > Hello,
> >
> > There is any provision for binary dependency on Gentoo/Portage? The
> > way it works now is quite messy with things like revdep-rebuild.
>
> Solving this is not trivial. Basically suppose application X depends on
> sys-libs/db-4.*
>
> This can be resolved by differently slotted libraries. We need to record
> which one was actually used (not easy by itself, but more an issue of the
> ebuild itself, if more than 1 candidate is available). But suppose that
> we know that the application was compiled to use db-4.3.29. We must then
> know that it is ok to replace the db-4.3.29 package with 4.3.30, but that
> it isn't ok to replace it by 4.3.28 or 4.4.20.
>
> To make this things worse, the above example assumes that within a slot,
> the libraries are binary compatible. There are examples of libraries that
> are not. And what about a library whose interface is dependent on a third
> library: B uses A, C uses B, but B exports A. So B is dependent on A, and
> the binary package of C must record that B was compiled with A.
>
> In short, welcome to binary package hell. This is the reason that binary
> distributions must use versions. Even debian. It is just very very hard
> to fix these kinds of indirect dependencies.

You're forgetting we're equally screwed when upstream (*cough* 
openssl) goes and changes the soname while preserving abi.

Old solution to it was to add another metadata key to ebuilds, 
"bincompat" that is compared within slotting to see if a rebuild of 
rdepend consumers needs to occur.

fex...
alsa-lib-0.90
slot=0
bincompat=0

alsa-lib-1.0
slot=0
bincompat=1

The pkg manager does it's little dance to figure out what should be 
installed where (and what versions can coexist), while doing it if 
it's going to replace a pkg and bincompat differs, pull in the subset 
of the state graph at that point (including vdb) that rdeps on that 
package/slot and force a rebuild of them.

As per the norm, requires a smart resolver; for c++ would expect 
cycles to occur where the only solution is to pull in libstdc++ (fex) 
to sidestep horkage while doing the rebuilds...

Also note that (like all general solutions) it's not going to be able 
to cover all insane stuff; if the api breaks in transitioning 
bincompat is going to cause a minor explossion that is only resolvable 
by packages specifying exact dependencies (read: version ranges).
~harring