Bug#879049: debian-policy: 4.9.1: Allow nodoc to be used to not create empty -doc packages
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
Reply to: