On 20/01/11 00:46, Pierre Chapuis wrote:
Real deps --------- A -> B,D B -> C C -> D,E
Current Arch way ---------------- A -> B B -> C C -> D,E
I think we have established the Transitive closure is impractical, so lets exclude that. The "current Arch way" has the advantage of speed in dependency resolution if B is installed, but suffers from potential breakage if C removes D from its dependency list. How common would such breakage be? I'd argue that it would be fairly rare as software tends to gather more dependencies and not less. Also, since spreading the word about building in chroots, bug reports about missing dependencies are much rarer, again indicating it is not a common occurrance. Given we are competent Linux users around here and can deal with what would be minor breakage, I'd lean towards taking the speed advantage and fix the rare bugs as they occur. So getting back to the original point of this thread... if D is glibc, for most packages there is zero chance of breakage by not listing it as a dep of A because it will be on all systems. So there is only advantages! Of course, some low level packages in [core] rely on having glibc installed before them for correct system installation and so glibc should be listed in their depends list. So no rule about the inclusion or not of glibc in the depends list can really be made... it is up to the packager to know what they are packaging and make their own decisions. So my conclusion is to only list glibc as a dependency if you are packaging low level stuff that will be installed during the initial installation of a system. Otherwise, leave it out. Allan