1 |
> To make this things worse, the above example assumes that within a slot, |
2 |
> the libraries are binary compatible. There are examples of libraries that |
3 |
> are not. And what about a library whose interface is dependent on a third |
4 |
> library: B uses A, C uses B, but B exports A. So B is dependent on A, and |
5 |
> the binary package of C must record that B was compiled with A. |
6 |
> |
7 |
> In short, welcome to binary package hell. This is the reason that binary |
8 |
> distributions must use versions. Even debian. It is just very very hard |
9 |
> to fix these kinds of indirect dependencies. |
10 |
|
11 |
I think that there are many reasons, why such kind of important thing |
12 |
should not be automatically generated. Starting from the fact that one |
13 |
thing is dependency in binary, another thing is knowledge if this |
14 |
combination actually works, has no bugs, should not be masked. |
15 |
|
16 |
Anyway, if such binary dependancyes should ever be used, then it would |
17 |
be best to: |
18 |
1. register version number of interfaces |
19 |
2. register interface groups |
20 |
|
21 |
I mean: |
22 |
If some lib supports commands turnon() and turnoff(), but one version |
23 |
supports additionally command int checkifturnedon() and another |
24 |
supports char checkifturnedon(), then there should be: |
25 |
* Interface group, which states only that there are turnon and turnoff |
26 |
functions -- as many apps use only most standard and minimalistic set |
27 |
of commands from one lib, there is no need to know if some advanced |
28 |
features are 0.9.80 or 0.9.64 compatible. |
29 |
* Two interface versions, 0.9.80a and 0.9.80b, for example |
30 |
|
31 |
All those interfaces and groups could be file links -- |
32 |
lib_interfacegroup_interface1.a would link to libinterface1.a. |
33 |
|
34 |
If there is 1 library with 2 sets of minimal functionality, then it's |
35 |
questionable, how to implement both (there would be linker error in |
36 |
some cases) -- which makes this conception weaker. |
37 |
|
38 |
Anyway, when standard interfaces are used and linked, that would help a bit. |
39 |
|
40 |
Anyway -- why should i check dependencies *after* building of a big |
41 |
pack, maybe hours of building, when i can check it without even |
42 |
downloading it, when there is nice portage tree? And, i think that |
43 |
making it binary would allow too much bad style -- there are imho |
44 |
things, which should not be automated without very-very careful |
45 |
thinking even if one can only win with automating them in theory and |
46 |
portage tree is most definitely one of them. |
47 |
|
48 |
> Paul |
49 |
> |
50 |
> -- |
51 |
> Paul de Vrieze |
52 |
> Gentoo Developer |
53 |
> Mail: pauldv@g.o |
54 |
> Homepage: http://www.devrieze.net |
55 |
> |
56 |
> |
57 |
> |
58 |
|
59 |
|
60 |
-- |
61 |
tvali |
62 |
(e-mail: "qtvali@×××××.com"; msn: "qtvali@×××××.com"; |
63 |
icq: "317-492-912") |
64 |
|
65 |
I like net more than life, cause if i do something wrong, then people |
66 |
in net will tell me that i do, so that i can fix it -- people in life |
67 |
will tell others that i do. |
68 |
|
69 |
-- |
70 |
gentoo-portage-dev@g.o mailing list |