Re: Bug#894441: dpkg-buildpackage: SOURCE_DATE_EPOCH must ignore bin-nmu changelog entries. Breaks M-A:same

[Guillem Jover <guillem@debian.org>]

On Fri, 2018-04-13 at 19:01:08 +0100, Ian Jackson wrote:
> > 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
> message here:
> 
>  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843773#75
> 
> That was in November 2016 and Guillem replied in January 2017 saying,
> essentially, that he still disagreed with the design of multiarch,

No. I think that refcounting in particular (not the entirety of
multiarch) was a misstep (even though it was me who proposed it on the
very early "design sprints"), trading apparent convenience and avoidance
of package increase for a correct and robust foundation. But as it was
also me, after having reverted the patch, the one accepting that path
forward given the rough consensus on debian-devel, I'm happy to share
the blame. I do take issue though, when people complain now that the
consequences of refcounting and binNMUs do not play well together,
because well, "I pretty much already told you so?".

> and that binNMUs are not coinstallable.

> AIUI binNMUs are now coinstallable ?  And that is why 

I think I might not have been explicit enough, but you might notice
there I'm talking about binNMUs with different binary versions (and
obviously same source version) not being in lockstep and not being
coinstallable. And no, they are still not coinstallable, and I'm not
planning on making them so.

> My solution is still applicable, I think.  There is no change to
> wanna-build needed.
> 
> 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 I also mentioned on my reply, but probably also not explictly
enough, this does not work if you install and remove current instances
and then install another instance. I'm not sure how you'd want dpkg to
track files for removed packages.

In your backup scenario, that would still trip it.

> As for Guillem's complaints about the design of multiarch: these
> concerns were overruled by a decision of the Technical Committee.

No. They were most definitely not. There's never been such ruling.
(And the only related ruling was in vain anyway…)

> I don't think they are good reasons to divert from the
> straightforward, if not entirely neat, course I propose.

That course is not a solution, I'm afraid.

Thanks,
Guillem