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
