Re: Please test gzip -9n - related to dpkg with multiarch support
* Ben Hutchings <ben@decadent.org.uk>, 2012-02-08, 20:23:
Relating to binNMU changelogs: do they really serve any purpose?
There are no source changes, so is there any real need for a changelog
change at all? AFAICT the only reason we do for historical reasons,
it being the only way previously to effect a version change.
We briefly discussed on #debian-buildd last week whether it was
possible to use --changes-option to override the distribution during
building. If it is also possible to override the version of the
generated .debs, this would make it possible to rebuild (NMU) without
messing around editing the changelog.
There are some source packages that always generate binary versions
different from the source version, e.g. linux-latest. They must
currently use dpkg-parsechangelog to get the default binary version. If
the binNMU is not mentioned in the changelog they would get the source
version and would not include any binNMU suffix in the generated binary
versions. We could make dpkg-parsechangelog obey a version override
too, but it's rather ugly!
(Hmm, it looks like linux-latest runs dpkg-parsechangelog at source
package build time so it's not binNMU-safe now. But this is fixable so
long as dpkg-parsechangelog makes binNMUs recognisable.)
Right. What we want to change is not how debian/changelog is being
modified by build software, but what happens to it when it lands in
/usr/share/doc/$pkgname/.
Packages could simply split debian/changelog into two parts:
/u/s/d/$p/changelog(.Debian).gz - the architecture-independent part;
/u/s/d/$p/changelog.binNMU-$arch.gz - the binNMU part.
That would have to be implemented in dh_installchangelogs and a few
M-A:same that don't use debhelper.
--
Jakub Wilk
Reply to: