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
