diff options
author | Sam Hartman <hartmans@debian.org> | 2021-07-09 10:50:09 -0600 |
---|---|---|
committer | Steve Langasek <steve.langasek@canonical.com> | 2021-09-15 17:52:39 -0700 |
commit | 01dd10ca3efd89193c3f0429064b54bc09501eec (patch) | |
tree | 815675c1d564deb2e4a9b073dcd075e966106f0f /debian/changelog | |
parent | 04d20bb46f932e9963676d5bc4aff5be052435f3 (diff) |
Revert "Prefer _PAM_ISA to DEFAULT_MODULE_PATH"
It turns out Debian uses DEFAULT_MODULE_PATH and _PAM_ISA in the opposite meaning of upstream. DEFAULT_MODULE_PATH is based on libdir, which is the multiarch path, while _PAM_ISA is /lib/security.
So my patch had the opposite effect as intended.
Diffstat (limited to 'debian/changelog')
-rw-r--r-- | debian/changelog | 17 |
1 files changed, 17 insertions, 0 deletions
diff --git a/debian/changelog b/debian/changelog index 592cda00..dee3f32b 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,20 @@ +pam (1.4.0-9) unstable; urgency=medium + + * Revert prefer the multiarch path from 1.4.0-8: It turns out that + Debian uses DEFAULT_MODULE_PATH and _PAM_ISA in the opposite meaning + of upstream. If I had read the patch header of + patches-applied/lib_security_multiarch_compat more closely I would + have noticed this. The effect of 1.4.0-9 is what is stated in the + 1.4.0-8 changelog: we prefer multiarch paths, but the original patch + did that. + * I did test this in 1.4.0-8, but my test design was flawed. I placed a + invalid shared object in /lib/security and confirmed it did not shadow + an object in /lib/x86_64-linux-gnu/security. However I realized + shortly after releasing 1.4.0-8 that a valid shared object in + /lib/security will shadow one in the multiarch path. + + -- Sam Hartman <hartmans@debian.org> Fri, 09 Jul 2021 10:55:02 -0600 + pam (1.4.0-8) unstable; urgency=high [ Hideki Yamane ] |