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.



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).

Attachment: pgpFDZuONXCnW.pgp
Description: PGP signature

Reply via email to