[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: