1 |
On Thursday 16 March 2006 15:18, tvali wrote: |
2 |
> > To make this things worse, the above example assumes that within a |
3 |
> > slot, the libraries are binary compatible. There are examples of |
4 |
> > libraries that are not. And what about a library whose interface is |
5 |
> > dependent on a third library: B uses A, C uses B, but B exports A. So |
6 |
> > B is dependent on A, and the binary package of C must record that B |
7 |
> > was compiled with A. |
8 |
> > |
9 |
> > In short, welcome to binary package hell. This is the reason that |
10 |
> > binary distributions must use versions. Even debian. It is just very |
11 |
> > very hard to fix these kinds of indirect dependencies. |
12 |
> |
13 |
> I think that there are many reasons, why such kind of important thing |
14 |
> should not be automatically generated. Starting from the fact that one |
15 |
> thing is dependency in binary, another thing is knowledge if this |
16 |
> combination actually works, has no bugs, should not be masked. |
17 |
> |
18 |
> Anyway, if such binary dependancyes should ever be used, then it would |
19 |
> be best to: |
20 |
> 1. register version number of interfaces |
21 |
> 2. register interface groups |
22 |
> |
23 |
> I mean: |
24 |
> If some lib supports commands turnon() and turnoff(), but one version |
25 |
> supports additionally command int checkifturnedon() and another |
26 |
> supports char checkifturnedon(), then there should be: |
27 |
> * Interface group, which states only that there are turnon and turnoff |
28 |
> functions -- as many apps use only most standard and minimalistic set |
29 |
> of commands from one lib, there is no need to know if some advanced |
30 |
> features are 0.9.80 or 0.9.64 compatible. |
31 |
> * Two interface versions, 0.9.80a and 0.9.80b, for example |
32 |
|
33 |
While theoretically one can't even know that the semantics are correct, we |
34 |
know from experience that hell will not break through. Downgrading |
35 |
libraries is always problematic though. It's not desirable enough to try |
36 |
to support it. |
37 |
|
38 |
> |
39 |
> All those interfaces and groups could be file links -- |
40 |
> lib_interfacegroup_interface1.a would link to libinterface1.a. |
41 |
|
42 |
Looking at a sub-package level is going to make things way too complex. I |
43 |
don't think that doing so is going to help gentoo/portage in any way. |
44 |
> |
45 |
> If there is 1 library with 2 sets of minimal functionality, then it's |
46 |
> questionable, how to implement both (there would be linker error in |
47 |
> some cases) -- which makes this conception weaker. |
48 |
> |
49 |
> Anyway, when standard interfaces are used and linked, that would help a |
50 |
> bit. |
51 |
|
52 |
IMHO we need to know from every "binary" or installed package which |
53 |
package version and slot was used to satisfy it. We also need to know |
54 |
which of those dependencies must be exported to packages which use this |
55 |
one. |
56 |
|
57 |
All this must also take useflags into account ;-) of course. |
58 |
|
59 |
> |
60 |
> Anyway -- why should i check dependencies *after* building of a big |
61 |
> pack, maybe hours of building, when i can check it without even |
62 |
> downloading it, when there is nice portage tree? And, i think that |
63 |
> making it binary would allow too much bad style -- there are imho |
64 |
> things, which should not be automated without very-very careful |
65 |
> thinking even if one can only win with automating them in theory and |
66 |
> portage tree is most definitely one of them. |
67 |
|
68 |
The difference between binary packages and tracking what is installed with |
69 |
which relations are very small. Basically once compiled, the candidates |
70 |
that may resolve a dependency are fewer. While a BINSLOT variable could |
71 |
be an option (Although I'm not sure whether this would be needed), we |
72 |
still need to know the minimal version of the package within the slot. |
73 |
|
74 |
It's not about checking dependencies after building. It's about seeing |
75 |
whether one should rebuild package B because it depends on package A that |
76 |
has been rebuilt. Perhaps package A is slotted, so I don't need to |
77 |
rebuilt. But then when I want to remove the old version, portage should |
78 |
realise that while the source dependencies are still met, the binary |
79 |
dependencies have not been met, so a rebuild is needed. |
80 |
|
81 |
Revdep-rebuild is not going to solve this. It is a hack because it does |
82 |
not work on portage/package level. It tries to understand the elf |
83 |
(executable) format and as a result it tries to find libraries and |
84 |
executables (can't find all though, if they are installed at the wrong |
85 |
place) that depend on a particular library. Then it tries to find the |
86 |
package that the dependant library/executable comes from. As however |
87 |
libraries may have unresolved symbols, some libraries (e.g. libapr-util) |
88 |
do not actually state their dependencies. |
89 |
|
90 |
Further revdep-rebuild does not work with downgrades, or with scripts or |
91 |
other things that are not in the elf format. Finally revdep-rebuild needs |
92 |
to scour the filesystem too much. |
93 |
|
94 |
Recording binary dependencies can be used to resolve this. It is however |
95 |
not easy to do. |
96 |
|
97 |
Paul |
98 |
|
99 |
-- |
100 |
Paul de Vrieze |
101 |
Gentoo Developer |
102 |
Mail: pauldv@g.o |
103 |
Homepage: http://www.devrieze.net |