Web lists-archives.com

Re: Depends/Recommends from libraries

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.)