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: Fri, 24 Mar 2006 11:24:06
In Reply to: Re: [gentoo-portage-dev] DB and binary dependency by tvali
1 On Thursday 23 March 2006 21:35, tvali wrote:
2 >
3 > BINSLOT is a new word for me.
5 Ok BINSLOT is normally slot. However in some cases packages are in the
6 same slot, but not binary compatible (like their libraries having a
7 different SONAME e.g. openssl-0.9.6 and 0.9.7 (iirc)).
9 >
10 > I dont see any meaning in calculating dependencies after build. There
11 > would be too much problems:
12 > * If any of packages you depend on, are masked, you get an error after
13 > build, but should get it before
15 Calculating after build is only for validating configurations. It allows
16 one to see whether one can merge binary package A on the current system
17 (this might not be the case even if the build dependencies allow it). It
18 further allows one to do proper cleaning of obsolete packages. One could
19 even use it to find that if say X is updated, all dependent packages
20 should be updated too.
22 > * In many cases, not only libs, but also headers are included from
23 > another pack [kernel headers, for example, as i have seen from error
24 > messages]
26 Header files come from packages that should be mentioned in the
27 dependencies.
29 > * You cant pre-calculate dependancies
31 Calculating dependencies automatically is diabolically hard. The fact that
32 we have a tree that largely works shows that predicting them works well.
33 The reason is that the dependencies are statically defined by the source
34 of the package. At those parts where people make mistakes, or the build
35 systems are broken, occur the dependencies could be verified by automatic
36 tools that check most dependencies. Doing that for native code is easiest
37 done by disecting the libraries and executables. For header files,
38 inclusion parsing is probably a good approach. But then look at what is
39 installed, not what was started with. The reason being that at what is
40 installed is no longer dynamic based on a configure script, but totally
41 static. The only disadvantage being that this only checks the current
42 combination of useflags+context. Many checks by many users would however
43 give a good test coverage.
45 > In cases, where both headers and libs are included from other pack,
46 > which is same on both cases, this is totally irrelevant for deps if
47 > this other pack is statically or dynamically used.
49 Not really, with a static library A and a static library B that uses the
50 static A, this dependency is only runtime when the interface of B exposes
51 the headers of A. If not, one could unmerge both the static library and
52 the headers and one could still compile against the library.
54 > In cases, where headers are in pack to be compiled and .so is in
55 > another package, i havent yet checked, how to understand if dependancy
56 > is binary -- i cant say for sure that this does not include some work
57 > from user.
59 Ok, let me clarify. With a binary dependency I mean the actual
60 requirements of a package once it has been compiled. In general one could
61 say that given a depend atom "sys-libs/db-4.*" could be statisfied by
62 ebuilds in 5 slots: db-4.{0,1,2,3,4}. The sourcecode does not care which
63 one is used. However, code compiled agaist db-4.0.14 will not run against
64 any libdb-4.{1,2,3,4}.*. This is because these should libraries live in
65 different BINSLOT's (in other words, they are incompatible). As these
66 libraries have different SLOT's they can coexist though. For a binary
67 package therefore it is necessary to record the version of db it was
68 actually compiled against. As this might be very strict I also want to
69 say that any package within the same BINSLOT with a higher version than
70 the one compiled against also works (as it does).
72 Paul
74 --
75 Paul de Vrieze
76 Gentoo Developer
77 Mail: pauldv@g.o
78 Homepage:


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