[debhelper-devel] Bug#859724: debhelper: please consider using a non-multiarch libexecdir in new compat levels

[Simon McVittie]

Package: debhelper
Version: 10.2.5
Severity: wishlist

In compat levels >= 9, debhelper defaults to

    --libexecdir=\${prefix}/lib/$multiarch
    --libdir=\${prefix}/lib/$multiarch

This can be problematic for multiarch, if a "registration" file in
a non-multiarch location (for example /usr/share/dbus-1/services for
D-Bus, /usr/share/thumbnailers for sandboxable thumbnailers in the
GNOME stack, or /lib/systemd/system or /usr/lib/systemd/user for systemd)
needs to reference a binary in ${libexecdir} or ${pkglibexecdir}.
The GNOME team has had issues with this for the gdk-pixbuf and librsvg
thumbnailers.

Using a non-architecture-varying libexecdir also makes it a lot simpler
to give debugging instructions that require running a daemon with special
options or environment variables, if that daemon is not normally run
manually and so should not be in $PATH. Writing autopkgtests or manual
test instructions based on GNOME-style installed-tests[1], which canonically
live in ${libexecdir}/installed-tests/mypackage, is similarly a lot simpler
if the libexecdir doesn't vary.

In Red-Hat-style (lib64) multilib, libexec programs are installed in
/usr/libexec regardless of architecture. I suspect that this means few
packages actually rely on having a multiarch-varying libexecdir, because
if they did, their co-installability would already be broken on
Red-Hat-style systems.

For the next compat level please consider defaulting to:

    --libexecdir=\${prefix}/lib
    --libdir=\${prefix}/lib/$multiarch (same as now)

(or perhaps even not overriding libexecdir at all, now that /usr/libexec
is officially blessed by FHS 3.0 - but this would require a Policy change[2].)

Regards,
    S

[1] https://wiki.gnome.org/Initiatives/GnomeGoals/InstalledTests
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787816