On Fri, 15 Jun 2018 at 14:37:04 +0200, Bill Allombert wrote:
> There are already 28 /usr/lib/TUPLE/*/bin directories in unstable.
> There are probably other directories with binaries not named bin.
>
> They are candidates for being moved to /usr/libexec, but they should
> probably go to /usr/libexec/TUPLE at least to avoid file conflicts.
Packages are free to continue to use /usr/lib/TUPLE/PACKAGE/bin if they
want to, even after /usr/libexec exists, and I think that should be
best-practice for any packages that would otherwise collide.
FHS 3.0 explicitly says that it's OK for packages to install helper
binaries into either /usr/lib{,64} or /usr/libexec, although they should
choose one or the other, not both; so we are not making these packages
immediately buggy by adopting FHS 3.0. One of the design principles
for FHS 3.0 was that most FHS 2.3 systems should be obviously FHS
3.0 compliant without changes. (The only counter-example I'm aware of
is /usr/bin/mh/, for which I added an exemption in my proposed patch
for now.)
I would anticipate that the way we move to /usr/libexec would be:
* maintainers who want it explicitly use
--libexecdir='${exec_prefix}/libexec' (some of these maintainers
are currently using --libexecdir='${libdir}', as I did in src:ostree,
for the reasons outlined in #859724)
* some future debhelper compat level (perhaps 12 or 13) changes the
dh_auto_configure defaults from --libexecdir='${libdir}' to the
Autoconf upstream default --libexecdir='${exec_prefix}/libexec'
(and maybe the same for non-Autotools build systems like CMake)
* when maintainers change their packages to that compat level, in
addition to adjusting their debian/*.install files, they are expected
to check that they aren't introducing multiarch non-coinstallability
in any Multi-Arch: same packages, and if necessary specify
--libexecdir='${libdir}' explicitly (I expect this to be rare in
practice)
* packages that install their helper binaries to ${libdir} or a
subdirectory are unaffected, and will continue to install them in
/usr/lib or a subdirectory indefinitely
Expanding on that last point, there are two ways an upstream can
install libexec-style helper binaries with Automake: they can put
them in ${libdir} (or more likely ${pkglibdir}) or they can put them
in ${(pkg)libexecdir}. For the former, the binaries would remain in
/usr/lib/TUPLE by default and there's no multiarch collision.
For the latter, if there was going to be a collision, then the maintainer
would have to deal with this at the time that they bump debhelper compat
level to opt-in to the changed behaviour; but I don't think this problem
case will happen much in practice, because the same upstream package would
already have been troublesome to install on Red-Hat-like biarch systems
where ${libdir} is /usr/lib{,64} but ${libexecdir} is always /usr/libexec,
so any affected upstream projects have probably already been fixed by
users of Red-Hat-like distros.
When switching from libexecdir=${libdir} to
libexecdir=${exec_prefix}/libexec, maintainers already need to check
that their package isn't breaking the expectations of other packages
(or older versions of their library that might still be in RAM), just
like they did at the transition from libexecdir=${libdir}/${DEB_SOURCE}
to libexecdir=${libdir} when moving from debhelper compat level 8 to 9
(or from cdbs to dh 9 for packages that used to use cdbs).
smcv
