Adam Borowski wrote: > I'd like to discuss (and then propose to -policy) the following rule: > > # Libraries which don't provide a convenient means of conditionally loading > # at runtime (this includes most libraries for languages such as C), SHOULD > # NOT declare a "Depends:" or "Recommends:" relationship, directly or > # indirectly, on packages containing anything more than dormant files. > # Those include, among others, daemons, executables in $PATH, etc. Any such > # relationship should be instead declared by programs that use the library > # in question -- it is up to them to decide how important the relationship > # is.
In general, I'd like to see something like this; I'd love to see the default install reduced, and Recommends made less painful to leave enabled. I think it'll need some more precise definition, though, on a few points: - Regarding packages that install running daemons, I agree with this entirely. I wonder if we could establish some kind of substvar mechanism similar to shlibdeps to make it easy for an application package to say "I want a Depends/Recommends/Suggests on whatever this -dev package's corresponding library needs to run". - A Depends with multiple alternatives, where the primary alternative meets this requirement, seems fine overall even if some of the alternatives would not meet this requirement. - I don't actually see any issue with a library having a Depends or Recommends on a package that provides a binary executable, such as a helper program. Most of the time such an executable would live in a library-specific directory under /usr/lib/, but if the program also has value for the end user to run directly, having it in $PATH seems fine. (In which case it *has* to go in a separate package, to avoid conflicts that would make the library not work with multiarch.) Installing a library and ending up with an additional executable seems far more reasonable than installing a library and ending up with a running daemon. As an example, consider something like libguestfs. Or consider any library that exists to wrap some command-line tool and give it an API. (Yes, the right answer is "refactor or rewrite the tool to put its implementation in a library", but that isn't always doable overnight.) - Configuration files seem fine, such as default configuration for programs using the library, even though in some cases I wouldn't describe such configuration as "dormant". - Plugins for other applications might consist of "libraries", but in those packages should not fall under this restriction. Likewise for PAM and NSS modules and similar. - While in general I would prefer not to see library packages asking debconf questions, I do see various libraries with dependencies on debconf. This would seem to prohibit that. And, of course, the usual issue of "policy shouldn't change to make large numbers of packages insta-buggy" applies. It's relatively easy to construct a package limit (hit 'l') to browse such packages in aptitude; just use this expression: ?section(libs) ?depends(?not(?or(?section(libs), ?name(^lib)))) (You may want to refine it further from there.)
