On Thursday 16 March 2006 15:18, tvali wrote: > > 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
While theoretically one can't even know that the semantics are correct, we know from experience that hell will not break through. Downgrading libraries is always problematic though. It's not desirable enough to try to support it. > > All those interfaces and groups could be file links -- > lib_interfacegroup_interface1.a would link to libinterface1.a. Looking at a sub-package level is going to make things way too complex. I don't think that doing so is going to help gentoo/portage in any way. > > 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. IMHO we need to know from every "binary" or installed package which package version and slot was used to satisfy it. We also need to know which of those dependencies must be exported to packages which use this one. All this must also take useflags into account ;-) of course. > > 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. The difference between binary packages and tracking what is installed with which relations are very small. Basically once compiled, the candidates that may resolve a dependency are fewer. While a BINSLOT variable could be an option (Although I'm not sure whether this would be needed), we still need to know the minimal version of the package within the slot. It's not about checking dependencies after building. It's about seeing whether one should rebuild package B because it depends on package A that has been rebuilt. Perhaps package A is slotted, so I don't need to rebuilt. But then when I want to remove the old version, portage should realise that while the source dependencies are still met, the binary dependencies have not been met, so a rebuild is needed. Revdep-rebuild is not going to solve this. It is a hack because it does not work on portage/package level. It tries to understand the elf (executable) format and as a result it tries to find libraries and executables (can't find all though, if they are installed at the wrong place) that depend on a particular library. Then it tries to find the package that the dependant library/executable comes from. As however libraries may have unresolved symbols, some libraries (e.g. libapr-util) do not actually state their dependencies. Further revdep-rebuild does not work with downgrades, or with scripts or other things that are not in the elf format. Finally revdep-rebuild needs to scour the filesystem too much. Recording binary dependencies can be used to resolve this. It is however not easy to do. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net
pgp9RhC4YUuuN.pgp
Description: PGP signature
