> To make this things worse, the above example assumes that within a slot,
> the libraries are binary compatible. There are examples of libraries that
> are not. And what about a library whose interface is dependent on a third
> library: B uses A, C uses B, but B exports A. So B is dependent on A, and
> the binary package of C must record that B was compiled with A.
> In short, welcome to binary package hell. This is the reason that binary
> distributions must use versions. Even debian. It is just very very hard
> to fix these kinds of indirect dependencies.

I think that there are many reasons, why such kind of important thing
should not be automatically generated. Starting from the fact that one
thing is dependency in binary, another thing is knowledge if this
combination actually works, has no bugs, should not be masked.

Anyway, if such binary dependancyes should ever be used, then it would
be best to:
1. register version number of interfaces
2. register interface groups

I mean:
If some lib supports commands turnon() and turnoff(), but one version
supports additionally command int checkifturnedon() and another
supports char checkifturnedon(), then there should be:
* Interface group, which states only that there are turnon and turnoff
functions -- as many apps use only most standard and minimalistic set
of commands from one lib, there is no need to know if some advanced
features are 0.9.80 or 0.9.64 compatible.
* Two interface versions, 0.9.80a and 0.9.80b, for example

All those interfaces and groups could be file links --
lib_interfacegroup_interface1.a would link to libinterface1.a.

If there is 1 library with 2 sets of minimal functionality, then it's
questionable, how to implement both (there would be linker error in
some cases) -- which makes this conception weaker.

Anyway, when standard interfaces are used and linked, that would help a bit.

Anyway -- why should i check dependencies *after* building of a big
pack, maybe hours of building, when i can check it without even
downloading it, when there is nice portage tree? And, i think that
making it binary would allow too much bad style -- there are imho
things, which should not be automated without very-very careful
thinking even if one can only win with automating them in theory and
portage tree is most definitely one of them.

> Paul
> --
> Paul de Vrieze
> Gentoo Developer
> Homepage: http://www.devrieze.net

icq: "317-492-912")

I like net more than life, cause if i do something wrong, then people
in net will tell me that i do, so that i can fix it -- people in life
will tell others that i do.

gentoo-portage-dev@gentoo.org mailing list

Reply via email to