On Wed, 18 Oct 2017 at 20:30:20 +0200, Bill Allombert wrote: > On Wed, Oct 18, 2017 at 02:16:48PM -0400, Jeremy Bicha wrote: > > I don't think there is any benefit to anyone from empty -doc packages. > > What about packages that depend on -doc packages ? > They might become uninstallable.
I can turn that around: what about packages that depend on -doc packages for a valid reason? They might be installable-but-broken, which seems worse than being uninstallable. If I can install (for example) the gnome-api-docs metapackage, it doesn't seem very useful or in keeping with the relevant maintainers' intentions for the documentation that it is intended to pull in to be missing? One of the design principles for build profiles (which are unfortunately not in Policy yet, #757760) was that if a package has functionally significant content, "profiled" builds that omit some or all of its functionality should not build it, instead of building it with different/missing functionality and misleadingly satisfying dependencies with a version of the package that might be considered broken. In the case of gtk-doc documentation (popular in GNOME but also used elsewhere), documentation can be functionally significant. Documentation built by gtk-doc has a mechanism for adjusting cross-references at build-time to point to a local copy of a dependency's documentation. For example, ostree depends on GLib; it has a Build-Depends-Indep on the GLib documentation, so that gtk-doc can read GLib's .devhelp file and rewrite external web links in libostree's documentation to be relative links into a local copy of GLib's documentation. If ostree's (arch-indep, non-nodoc-profile) build was allowed to go ahead with an empty version of libglib2.0-doc installed, its result would be different (admittedly only slightly, but reproducible builds are something we want, so that should be considered a bug). I suspect gtk-doc is not the only documentation system with similar properties. smcv