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 |