Simon McVittie writes ("Re: Bug#1104854: binNMUs can cause ma-same violations 
in eg manpages"):
> On Wed, 07 May 2025 at 13:48:19 +0100, Ian Jackson wrote:
> >Rebuilds are arch-specific, so the binNMU
> >number can vary across architectures, just as the bdate can:
> >  https://packages.debian.org/sid/libopts25-dev
> 
> They can, but according to the rules applied by dpkg/apt for multiarch,
> instances of the same binary package with a different version number are 
> not eligible for co-installation, even if they are both M-A:same, so 
> it's OK for their contents to be different.

Ah.  Right.

Gosh, this is all very complicated.

It seems anomalous that we (i) schedule binNMUs on each architecture
separately but (ii) they must all be aligned.  This leads to suggest
another option
   E. Always schedule rebuilds on all arches, so they all
      have identical bdates.
(this may be quite hard or a bad idea for other reasons).  And of
course we have:

   F. Abolish binNMUs and just do no-change source-only uploads.
      tag2upload might make this much easier...

Anyway,

I think that means Chris's option D would work.  I have to say this
addition of +1 second feels like a bodge to me, although I can't
immediately think of a way it would go wrong other than merely
confusing humans.  (If we go with this option we should maybe pick a
larger value of 1 - aren't there some filesystems with >1s timestamp
granularity?  2 might be better.)

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Reply via email to