HiVersion 13.21 of debhelper has just been uploaded to unstable with some compat 14 related changes.
The changes should generally not have any negative consequences for you unless you have files that must **not** have the "user write bit" and `dh_fixperms` does not know it should remove that bit. This is exceedingly unlikely since the default permissions are 0644/0755 and the major exceptions like `*.ali` and `etc/sudoers.d` is covered by `dh_fixperms`. Nevertheless, this is the "subscribe for updates" bug and it is an update, so here goes:
- When running dh_auto_install, debhelper provided build systems.
will now ensure all paths
in the destdir have minimal user permissions (chmod -R u+rwX)
to avoid weird permission
denied errors during builds.
Third-party provided debhelper build systems are recommended to
support this as well.
This can be done by running
$this->ensure_minimal_permissions($destdir) if not
compat(13);
in the debhelper Buildsystem code from their sub install
implementation after the
upstream code has been run.
If you are not using dh_auto_install and you run into weird
permission denied errors, you
can often solve this by running chmod -R u+rwX DIRECTORY after
running the install target
from the upstream build system.
Please take care to check if your package has any special cases
for permissions where
files or directories for some reason must not have the "user write
bit" set. Known cases
are *.ali files and /etc/sudoers.d, which dh_fixperms will fix
up by default.
The problem with uncommon permissions have always been present
in theory. However, it has
become considerable more visible with dh_fixperms being run
later in the sequence as of
compat 14 and with the move to remove fakeroot by default
(which papered over some of
these issues). This change is aimed at mitigating the problem.
Thanks to Andrea Pappacoda <and...@pappacoda.it> for reporting the bug in #1082724.
Best regards, Niels
OpenPGP_signature.asc
Description: OpenPGP digital signature
