Gentoo Archives: gentoo-portage-dev

From: Brian Harring <ferringb@×××××.com>
To: gentoo-portage-dev@l.g.o
Subject: Re: [gentoo-portage-dev] DB and binary dependency
Date: Thu, 16 Mar 2006 14:24:50
In Reply to: Re: [gentoo-portage-dev] DB and binary dependency by Paul de Vrieze
1 On Thu, Mar 16, 2006 at 02:58:00PM +0100, Paul de Vrieze wrote:
2 > On Wednesday 15 March 2006 16:13, Gustavo Sverzut Barbieri wrote:
3 > > Hello,
4 > >
5 > > There is any provision for binary dependency on Gentoo/Portage? The
6 > > way it works now is quite messy with things like revdep-rebuild.
7 >
8 > Solving this is not trivial. Basically suppose application X depends on
9 > sys-libs/db-4.*
10 >
11 > This can be resolved by differently slotted libraries. We need to record
12 > which one was actually used (not easy by itself, but more an issue of the
13 > ebuild itself, if more than 1 candidate is available). But suppose that
14 > we know that the application was compiled to use db-4.3.29. We must then
15 > know that it is ok to replace the db-4.3.29 package with 4.3.30, but that
16 > it isn't ok to replace it by 4.3.28 or 4.4.20.
17 >
18 > To make this things worse, the above example assumes that within a slot,
19 > the libraries are binary compatible. There are examples of libraries that
20 > are not. And what about a library whose interface is dependent on a third
21 > library: B uses A, C uses B, but B exports A. So B is dependent on A, and
22 > the binary package of C must record that B was compiled with A.
23 >
24 > In short, welcome to binary package hell. This is the reason that binary
25 > distributions must use versions. Even debian. It is just very very hard
26 > to fix these kinds of indirect dependencies.
28 You're forgetting we're equally screwed when upstream (*cough*
29 openssl) goes and changes the soname while preserving abi.
31 Old solution to it was to add another metadata key to ebuilds,
32 "bincompat" that is compared within slotting to see if a rebuild of
33 rdepend consumers needs to occur.
35 fex...
36 alsa-lib-0.90
37 slot=0
38 bincompat=0
40 alsa-lib-1.0
41 slot=0
42 bincompat=1
44 The pkg manager does it's little dance to figure out what should be
45 installed where (and what versions can coexist), while doing it if
46 it's going to replace a pkg and bincompat differs, pull in the subset
47 of the state graph at that point (including vdb) that rdeps on that
48 package/slot and force a rebuild of them.
50 As per the norm, requires a smart resolver; for c++ would expect
51 cycles to occur where the only solution is to pull in libstdc++ (fex)
52 to sidestep horkage while doing the rebuilds...
54 Also note that (like all general solutions) it's not going to be able
55 to cover all insane stuff; if the api breaks in transitioning
56 bincompat is going to cause a minor explossion that is only resolvable
57 by packages specifying exact dependencies (read: version ranges).
58 ~harring


Subject Author
Re: [gentoo-portage-dev] DB and binary dependency Paul de Vrieze <pauldv@g.o>