Gentoo Archives: gentoo-portage-dev

From: Paul de Vrieze <pauldv@g.o>
To: gentoo-portage-dev@l.g.o
Subject: Re: [gentoo-portage-dev] DB and binary dependency
Date: Thu, 16 Mar 2006 14:48:22
In Reply to: Re: [gentoo-portage-dev] DB and binary dependency by tvali
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
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.
38 >
39 > All those interfaces and groups could be file links --
40 > lib_interfacegroup_interface1.a would link to libinterface1.a.
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.
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.
57 All this must also take useflags into account ;-) of course.
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.
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.
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.
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.
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.
94 Recording binary dependencies can be used to resolve this. It is however
95 not easy to do.
97 Paul
99 --
100 Paul de Vrieze
101 Gentoo Developer
102 Mail: pauldv@g.o
103 Homepage: