Bug#1059395: libacl1, debhelper: changelog handling with --no-trim seems to be not binNMU-safe
Package: libacl1,debhelper
Control: found -1 libacl1/2.3.1-3
Control: found -1 debhelper/13.11.9
Severity: important
X-Debbugs-Cc: debian-release@lists.debian.org
libacl1 was recently binNMU'd on all architectures to address version skew.
Unfortunately, the binNMU'd version is no longer multiarch co-installable
because its changelog differs between architectures:
│ │ ├── ./usr/share/doc/libacl1/changelog.Debian.gz
│ │ │ ├── changelog.Debian
│ │ │ │ @@ -1,13 +1,13 @@
│ │ │ │ acl (2.3.1-3+b1) sid; urgency=low, binary-only=yes
│ │ │ │
│ │ │ │ - * Binary-only non-maintainer upload for amd64; no source changes.
│ │ │ │ + * Binary-only non-maintainer upload for i386; no source changes.
│ │ │ │ * Rebuild to sync binNMU versions
│ │ │ │
│ │ │ │ - -- all / amd64 / i386 Build Daemon (x86-conova-01) ...
│ │ │ │ + -- i386 Build Daemon (x86-grnet-01) ...
This binNMU changelog entry would normally be separated into
changelog.Debian.${DEB_HOST_ARCH}.gz, as can be seen in
/usr/share/doc/libxext6/ at the time of writing. However, that mechanism
doesn't seem to have been effective for libacl1.
I notice that libacl1 uses dh_installchangelogs --no-trim in its
debian/rules to suppress the default exclusion of older changelog
entries. It appears that using that option also suppresses the separation
of binNMU changelog entries into a separate file? I think it probably
should not, because the trimming of old changelog entries is merely
a nice-to-have to save some disk space, but the separation of binNMU
changelog entries is functionally necessary if we want packages to remain
multiarch co-installable across binNMUs.
A sourceful upload of libacl1 would temporarily address this (until the
next binNMU) by not being a binNMU, but would not be a long-term solution,
unless we stop using binNMUs entirely and replace them with "no-changes"
machine-assisted sourceful uploads like Ubuntu has done.
Not using --no-trim could address this from the libacl1 side, but
presumably the libacl1 maintainer has used that option intentionally and
for a reason. (Is that reason more important than having co-installable
binNMUs?)
Making --no-trim only disable the trimming of old changelog entries, but
retain the separation of binNMU changelog entries (and then binNMU'ing
libacl1 again) could address this from the debhelper side.
I don't know which of these ways forward is the right one. Please reassign
or clone as appropriate, and in the meantime please consider doing a
sourceful upload of libacl1 to unblock multi-arch co-installability.
Thanks,
smcv
Reply to: