Re: Bug#894441: dpkg-buildpackage: SOURCE_DATE_EPOCH must ignore bin-nmu changelog entries. Breaks M-A:same
- To: Philipp Kern <firstname.lastname@example.org>
- Cc: Aurelien Jarno <email@example.com>, firstname.lastname@example.org, email@example.com, Holger Levsen <firstname.lastname@example.org>, Guillem Jover <email@example.com>, Jean-Michel Vourgère <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, Chris Lamb <email@example.com>, Julien Cristau <firstname.lastname@example.org>
- Subject: Re: Bug#894441: dpkg-buildpackage: SOURCE_DATE_EPOCH must ignore bin-nmu changelog entries. Breaks M-A:same
- From: Ian Jackson <email@example.com>
- Date: Fri, 13 Apr 2018 19:01:08 +0100
- Message-id: <[🔎] firstname.lastname@example.org>
- In-reply-to: <[🔎] email@example.com>
- References: <[🔎] 1527368.PPXLdF6bC9@deimos> <[🔎] firstname.lastname@example.org>
> On Thu, Apr 05, 2018 at 05:43:58PM +0200, Jean-Michel Vourgère wrote:
> > So, during compilation:
> > SOURCE_DATE_EPOCH must ignore bin-nmu changelog entries
> > because it breaks Multi-Arch:same on bin-nmu.
> > During dpkg-deb (:
> > SOURCE_DATE_EPOCH must *not* ignore bin-nmu changelog entries
> > because it would break software relying on files mtime.
I don't think we are as doomed as all that. I analysed this in my
That was in November 2016 and Guillem replied in January 2017 saying,
essentially, that he still disagreed with the design of multiarch, and
that binNMUs are not coinstallable.
AIUI binNMUs are now coinstallable ? And that is why
My solution is still applicable, I think. There is no change to
There is a resulting small wrinkle that the on disk mtime of a
multi-arch shared file may the mtime of any of the source packages.
Guillem complains that it would make verification difficult, but I
think that is a soluble problem. Guillem also complains that the
mtime may flap; but that is easily avoided by having the on-disk mtime
only go forwards.
As for Guillem's complaints about the design of multiarch: these
concerns were overruled by a decision of the Technical Committee.
I don't think they are good reasons to divert from the
straightforward, if not entirely neat, course I propose.
Ian Jackson <email@example.com> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.