Simon McVittie:
> Package: debhelper
> Version: 13.4
> Severity: normal
> File: /usr/bin/dh_fixperms
>
> In debhelper 13.4, usr/libexec was added to the array @executable_files_dirs
> of directories in which all files are to be made executable.
>
> I'm not sure that this is necessarily appropriate: several packages install
> files into subdirectories of /usr/libexec that are not directly executable.
> In particular:
>
> * There is a convention in GLib and GLib-adjacent packages to install
> "as-installed" integration test suites (for use by e.g. autopkgtest),
> including both executables and non-executable data, into
> /usr/libexec/installed-tests
> * Valgrind uses /usr/libexec/valgrind for private data that is
> a mixture of executables, non-executable XML files, and shared libraries
> * sudo uses /usr/libexec/sudo for plugins
>
> [...]
>
> I would personally take option 2 and process the @executable_files_dirs
> non-recursively, if it was up to me, because all the use-cases that
> I'm aware of for mixing executable and non-executable files in the
> ${libexecdir} also want to group them into a subdirectory. The other
> @executable_files_dirs don't generally have subdirectories (the only
> counterexamples I know of are /usr/bin/mh/, which has a special exception
> in Policy, and some mh-like mail suites) so processing the other
> directories non-recursively shouldn't have any practical effect on many
> packages.
>
Thanks for the analysis. I am happy to review a patch or a MR to this
effect. :)
> In any case, I would hope that we can assume that upstream build systems
> usually chmod executables +x without dh_fixperms' help, because if they
> didn't do that, they would not work as expected in a manual installation
> from source code or in a non-Debian packaging system.
>
> Thanks,
> smcv
>
> [...]
Note that `dh_fixperms` is also used by packages where people manually
add a debian specific script to /usr/bin (etc.) besides the upstream
build system (or where there is no upstream build system at all). Here
it is useful as you cannot set mode (or ownership) via d/install.
Thanks,
~Niels
