On 2011-01-22 01:29 +1000 (03:6) Allan McRae wrote: > On 22/01/11 00:43, Xyne wrote: > > Allan McRae wrote: > > > >> I pointed out that hard rules are not good. e.g. coreutils should (and > >> does) depend on glibc as it is not guaranteed that glibc is installed at > >> the time when you first install coreutils (which is likely the initial > >> install). But there is no point putting glibc in the depends list for > >> (e.g.) openoffice-base as it will be installed by that stage. > > > > That's irrelevant to this discussion because it's a bootstrapping issue. I > > don't know how cyclical dependencies and other initialization problems > > should > > be handled, but they constitute a special case that should be detected and > > dealt with separately. > > Isn't this exactly the issue here? The original question was whether we > should include glibc in the dependency list for a package. I pointed > out a case where including glibc in the depends is critical and a case > where it is a waste of time, indicating there is no one answer to such a > question.
Sorry, I misread your reply. Ignore what I wrote. > > > >> Two points to consider: > >> 1) How much more complicated would it be to list all dependencies? > >> > >> > readelf -d $(pacman -Qql openoffice-base) 2>/dev/null | grep NEEDED | > >> sort | uniq | wc -l > >> 150 > >> > >> That is a lot of libraries... although some will be in the same package > >> so that is an upper estimate. But that is only libraries and the > >> complete dep list will be longer than that. > > > > I agree that is a lot. Of course we can't reasonably expect a packager to > > manually enter 150 libraries into a PKGBUILD, but are all of those direct > > dependencies? Maybe this is a silly question due to my ignorance of linking, > > but are any of those libraries linked via other packages? For example, if > > bar > > provides code that links to baz, and foo builds against bar, would baz turn > > up > > in the readelf output for foo? If the answer is yes, then baz would not be a > > dep of foo, even if foo links to it, because the linking was established > > "indirectly", i.e. bar could have used something else. > > > > Of course, in that case, baz would be a strict runtime dependency (unless > > sodeps could resolve this, but again, my understanding here is limited), but > > from a graph-theory pov, foo would only depend on bar. Such a situation > > would > > only require a rebuild, just as it would now (i.e. if baz were replaced by > > something else). > > The answer is no. "readelf -d" only lists directly linked libraries. > "ldd" gives the entire link chain. So if I wrote bindings to libalpm in Haskell (haskell-libalpm) and then created a package with a binary that used those bindings (foo), then readelf's output would not indicate libalpm? > > >> 2) It is worth the effort? We have very few bug reports about missing > >> dependencies and most (all?) of those fall into the category of missed > >> soname bumps or due to people not building in chroots. I.e. these are > >> because of poor packaging and not because we make assumptions about what > >> packages are installed or the dependencies of dependencies. > >> > >> > >> So I see making a change to the current approach as making things (1) > >> more complicated for (2) no real benefit. > > > > The answer depends on the answer to my previous question. The current system > > does indeed work, but it provides no strict guarantees. I think good > > practice > > in general is to make something that is critical as reliable and > > future-proof > > as possible, and I see that as a true benefit. It's like wanting to agree > > upon > > an open specification instead of just letting everyone do it their way and > > hope > > for a triumph of common sense. > > > > Admittedly, I doubt it would be a problem in the future and I'm discussing > > this > > idealistically. > > Idealistically, I might even agree with you. I just think it is not a > practical thing to do. And if we move away from just using binary > libraries as examples, we can find situation where we can make > guarantees that a dep of a dep will never be removed. > > e.g. I have a some perl software that depends on the perl-foo module. > If we list all dependencies, I would need to list perl and perl-foo. > But I can guarantee that perl-foo will always depend on perl, so do I > really need to list perl as a dep? Well, I list perl as a dep even for packages that depend on perl-* packages, but foo-* packages are a special case in that they necessarily depend on foo further down the chain. The same cannot be said for other implicit dependencies. > > > As for complication, even if there were a large number of deps to consider, > > there would likely be ways to generate at least a tentative list using > > simple > > tools. It could then be refined through feedback.* > > Again, I think this is too idealistic. Our current dependency checking > tool (namcap) has a lot of issues determining the dependencies of a > package and it is not be refined much at all... Maybe not "simple" tools then, but it should be possible to create something that can generate a list, e.g. a sandbox tool that can determine which libraries etc are accessed at build time and run time, which could then be mapped back to package. Forget that for a moment though and answer this instead: Can you think of any way other than direct specification that would guarantee that all dependencies are installed with a package (presuming that we know exactly what a package depends on). E.g. if a package depends on foo and foo-bar, then foo-bar clearly suffices, but how would you formally guarantee something such as glibc?