Hi! On Wed, 2025-05-07 at 12:42:25 +0100, Ian Jackson wrote: > Package: debian-policy > User: [email protected] > 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
