Re: Please test gzip -9n - related to dpkg with multiarch support
On Wed, Feb 08, 2012 at 07:54:47PM +0000, Roger Leigh wrote:
> On Wed, Feb 08, 2012 at 11:47:19AM -0800, Russ Allbery wrote:
> > Guillem Jover <guillem@debian.org> writes:
> > > On Wed, 2012-02-08 at 13:19:17 +0000, Ian Jackson wrote:
> > > And while the binNMU changelog issues might seem like a corner case,
> > > it's just a symptom of something that's not quite right.
> >
> > Also true. In fact, it's something that's been bothering me for a long
> > time with linked doc directories. I'd like to prohibit them in more cases
> > so that we get the binNMU changelogs on disk.
>
> 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.)
Ben.
--
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
- Albert Camus
Reply to: