Gentoo Archives: gentoo-portage-dev

From: Gustavo Sverzut Barbieri <barbieri@×××××.com>
To: gentoo-portage-dev@l.g.o
Subject: Re: [gentoo-portage-dev] DB and binary dependency
Date: Mon, 20 Mar 2006 18:58:39
Message-Id: 9ef20ef30603201057j66d7d6f7x632e7ace92d7d2c8@mail.gmail.com
In Reply to: Re: [gentoo-portage-dev] DB and binary dependency by Paul de Vrieze
1 I'm replying to this one, but I've read the whole thread...
2
3
4 On 3/16/06, Paul de Vrieze <pauldv@g.o> wrote:
5 > On Wednesday 15 March 2006 16:13, Gustavo Sverzut Barbieri wrote:
6 > > Hello,
7 > >
8 > > There is any provision for binary dependency on Gentoo/Portage? The
9 > > way it works now is quite messy with things like revdep-rebuild.
10 > >
11 > > I have an idea to "solve" this problem: after software is build, you
12 > > check which files it links (ldd binaries libraries) and check the used
13 > > against installed packages. If a library is not provided by an
14 > > installed package we could have a policy to inform user or just abort
15 > > installation.
16 > >
17 > > Also, if we implement these dependencies in rpm-generator, we could
18 > > just generate RPM packages and install it in the RPM-DB and let it
19 > > handle these kind of things.
20 > >
21 > > With these in place emerge would handle the build stage (where it
22 > > excels), but rpm would handle the binary installation and dependencies
23 > > (where it excels).
24 >
25 > Solving this is not trivial. Basically suppose application X depends on
26 > sys-libs/db-4.*
27 >
28 > This can be resolved by differently slotted libraries. We need to record
29 > which one was actually used (not easy by itself, but more an issue of the
30 > ebuild itself, if more than 1 candidate is available). But suppose that
31 > we know that the application was compiled to use db-4.3.29. We must then
32 > know that it is ok to replace the db-4.3.29 package with 4.3.30, but that
33 > it isn't ok to replace it by 4.3.28 or 4.4.20.
34 >
35 > To make this things worse, the above example assumes that within a slot,
36 > the libraries are binary compatible. There are examples of libraries that
37 > are not. And what about a library whose interface is dependent on a third
38 > library: B uses A, C uses B, but B exports A. So B is dependent on A, and
39 > the binary package of C must record that B was compiled with A.
40 >
41 > In short, welcome to binary package hell. This is the reason that binary
42 > distributions must use versions. Even debian. It is just very very hard
43 > to fix these kinds of indirect dependencies.
44
45 I do think you're overcomplicating things where you shouldn't.
46
47 Declaring stuff manually will always break, and to ensure a safe
48 system, it's better to use compiler information.
49
50 So I wouldn't mind fixing it to one package instead of a slot.
51
52 I mean, if user compiled software X-1.0 and it depends on library
53 Y-2.0, provided at the moment of X-1.0 compilation by package Z-3.0,
54 then make X-1.0 depend on Z-3.0.
55
56 If you were to remove Z-3.0 or upgrade it or even add other option by
57 means of USE, have X-1.0 to be recompiled too... you could be even
58 more correct to make it check CFLAGS too.
59
60 Of course this correctness could piss users, then you could have a
61 --nodeps or something like that to avoid this and use the old
62 behaviour.
63
64 --
65 Gustavo Sverzut Barbieri
66 --------------------------------------
67 Jabber: barbieri@×××××.com
68 MSN: barbieri@×××××.com
69 ICQ#: 17249123
70 Skype: gsbarbieri
71 Mobile: +55 (81) 9927 0010
72 Phone: +1 (347) 624 6296; 08122692@××××××××××××××.com
73 GPG: 0xB640E1A2 @ wwwkeys.pgp.net
74
75 --
76 gentoo-portage-dev@g.o mailing list

Replies

Subject Author
Re: [gentoo-portage-dev] DB and binary dependency tvali <qtvali@×××××.com>