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

[Ian Jackson]

Guillem Jover writes ("Re: Bug#894441: dpkg-buildpackage: SOURCE_DATE_EPOCH must ignore bin-nmu changelog entries. Breaks M-A:same"):
> On Fri, 2018-04-13 at 19:01:08 +0100, Ian Jackson wrote:
> > 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.

Ah.  Well, OK.  From my POV I am mainly trying to solve, here, the
"wrong timestamp breaks backups" problem.  If binNMUs are not
coinstallable then that's out of scope right now although IMO we
shouldn't do something now that would make it harder.  I think my
proposal does not make that harder.

> > 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.

I don't expect dpkg to track files for removed packages.

My scheme does not always manage to avoid unnecessary backing-up of
files which actually contain identical contents.  But I don't think
that is a necessary design goal.

It would be good to avoid unnecessary backing-up where possible and I
think my scheme does it in many such cases.  It does indeed miss some
cases involving removal and reinstallation of a particular .deb.  I
don't think that matters very much.

I think that my proposal will always result in a file being backed up
when needed, if the backup arrangements are correct.

When I said "the on-disk mtime only go forwards" I meant in the usual
case where packges are upgraded rather than downgraded.  I still want
the on-disk mtime to be one of the mtimes of the .debs which contained
this version of the file.

And this rule is only there to avoid the mtime flapping as a result of
a series of single-arch binNMUs which you now say cannot occur...

Ian.