1 |
On Thursday 23 March 2006 21:35, tvali wrote: |
2 |
> |
3 |
> BINSLOT is a new word for me. |
4 |
|
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)). |
8 |
|
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 |
14 |
|
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. |
21 |
|
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] |
25 |
|
26 |
Header files come from packages that should be mentioned in the |
27 |
dependencies. |
28 |
|
29 |
> * You cant pre-calculate dependancies |
30 |
|
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. |
44 |
|
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. |
48 |
|
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. |
53 |
|
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. |
58 |
|
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). |
71 |
|
72 |
Paul |
73 |
|
74 |
-- |
75 |
Paul de Vrieze |
76 |
Gentoo Developer |
77 |
Mail: pauldv@g.o |
78 |
Homepage: http://www.devrieze.net |