Bug#1104854: binNMUs can cause ma-same violations in eg manpages
Hi!
On Wed, 2025-05-07 at 12:42:25 +0100, Ian Jackson wrote:
> Package: debian-policy
> User: reproducible-builds@lists.alioth.debian.org
> Usertags: timestamps
> Background: We usually use binNMUs for rebuilds. That involves a
> binNMU-specfic arch-specific d/changelog fragment which is logically
> added to the source changelog. That has the date of the binNMU
> request. (Let's call that the "bdate" and the original source package
> changelog date the "sdate".)
>
> Since #843773, SOURCE_DATE_EPOCH (henceforth, S_D_E) has been set to
> the binNMU date in binNMUs. (In normal uploads its set to the sdate.)
> This is because otherwise we have this scenario:
>
[…]
>
> However, if S_D_E influences the *contents* of shared files in an
> ma-same package, we end up with a ma-same violation.
> Apparently this has happened in libopts25-dev, in manpages.
Most of this was already covered in for example
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843773#132, or in
the referenced megathread where the compromise to reintroduce
the Multi-Arch:same ref-counting was reached due to popular demand.
The root problem for all of this is still though, that Multi-Arch:same
ref-counting is an apparent convenience that avoided the up-front
cost of package content splits and making copyright and changelog
files proper dpkg metadata (in the .deb control member), that we have
instead been paying with at least, less robustness (the timestamps and
contents issues), more difficult dependency resolution and transitions
(version lockstep), and breakage on existing very convenient mechanisms
(like binNMUs).
The SOURCE_DATE_EPOCH issue reported here, and multiple other
arguments brought up in the bug report / thread, look like a
distraction to me. I agree with Russ that using that for the date in a
man page is perfectly fine, and I'm happy I don't have to manually track
release dates manually any longer. The problem is that the co-installable
ref-counting is just fragile. Even w/o binNMUs (which are also getting
IMO unjustly blamed here), a package might end up with different contents
for ref-counted files if the builds happen at different points in time.
To use an example brought up in the thread, if foo_1.0_amd64.deb gets
built at time T+0 and foo_1.0_armel.deb gets build at time T+1, where
they use a different pod2man version that generates different output,
then regardless of SOURCE_DATE_EPOCH we also get a M-A:same file
conflict (this was known at the time of the compromise).
The binNMU idea/mechanism also seems generally fine, the way it has
worked historically is "just" :) not compatible with M-A:same
ref-counting. In their current form, they pose problems due to the same
binNMU revision being potentially reused for different reasons, with
different changelog contents and dates (this last one will be a
problem with dpkg file metadata tracking). As mentioned in the above
referenced bug report, this also seems bogus (in the current context,
they were fine before), and binNMU revisions should be allocated as
unique global indexes with the same timestamp (and ideally the exact
same changelog entry (including maintainer), which would remove the
need for the changelog hacks we currently use). More so given that with
M-A:same ref-counting any binNMU that affects such package will need to
be performed for all architectures (regardless of those being affected)
to get the package in version lockstep anyway (which is also one of the
additional costs we are paying for).
While the current situation can be somewhat improved (see the binNMU
issue above), I'd hope we do not have to keep papering over that root
problem with more workarounds or additional unnecessary complexity for
something that was known to be the way it is at the time we opted into
it. :/
(In this case, I'd argue any such generated man page should be split
into their own -doc or -common or whatever package anyway.)
Thanks,
Guillem
Reply to: