Hi! On Mon, 2023-05-22 at 18:17:44 -0700, Steve Langasek wrote: > On Fri, May 19, 2023 at 05:34:56AM +0200, Guillem Jover wrote: > > Enabling time64 explicitly is what also had first come to my mind, > > which does not seem too onerous if all the debhelper override > > disappears? :) Then NEW processing could be done in one go to let the > > flood gates open at a specific coordinated date and time range (or > > staged via NEW into experimental, then mass uploaded to unstable to > > reduce the pressure on the ftpmaster(s) having to approve those), at > > which point dpkg could also be uploaded with the default switched. > > The difference in my view is that the changes to handle Provides: are > something that should persist in the packaging (until the next soname > change, at which point it's easy to handle as part of the overall renaming), > whereas explicit changes to set DEB_BUILD_OPTIONS to the future default are > something that ideally would be dropped immediately after dpkg-buildflags is > updated, and could (though unlikely) be a source of bugs later. I'd prefer > to avoid any transition plan which means I should be NMUing all of the > affected library packages twice.
I think I understand where you are coming from, and I see how ideally these would be dropped soon, but I also don't see this as a pressing matter that would even need NMUs, as the explicit settings should map to the then current defaults. Of course that precludes those defaults then changing globally in the future, but if needed (!?) that could be handled later on. But again, I think the flag day can potentially be done in multiple other ways that might avoid the breakage w/o needing these changes, and if so I'm happy with that as well. > Either way, we will need to come to some sort of decision about what to do > on i386 before we can move forward. How should we reach that decision? Are > you persuaded by the arguments presented in this thread? I think it depends a bit on the overall timing and support guarantees. If say i386 was to be dropped very soon from the archive, then it does not seem to me that making it an exception might be a good trade-off, because people could then use an unsupported release for time32 and a later unsupported one for time64 if they want to use either of those ABIs. If there is a will to keep it longer (either as a full or partial arch), then that changes the equation and it depends what people would value more between ABI compat or time64-ready. I think I covered part of this in <https://lists.debian.org/debian-devel/2023/05/msg00228.html>. So if there's consensus either way, I'm OK with that, but given that this is a matter of trade-offs and what we'd want to support, Helmut's proposal for a GR also sounds very enticing TBH, and would be a clear signal and remove ambiguity over what the project wants to do. > > Hmm, rechecking the script, I think we'd want to at least > > unconditionally add the Breaks and Replaces (no need for substvars > > then), otherwise we'd get upgrade errors? > > > That would leave only the Provides as potentially conditional… > > You're absolutely right, thanks for catching this! Fixed in git. As hinted above, I think the source:Version substvar should be switched to a hardcoded version at the point the migration was done, otherwise it will be floating forward and not catch older affected versions? > > > And btw, given the analysis that there are likely < 100 shared libraries > > > overall whose ABI changes when enabling LFS, this might be a change we > > > want > > > to consider in the trixie cycle as well - just preferably not bundled with > > > the time_t transition at the same time, as that would just cause more > > > delays > > > for testing migration vs splitting the two transitions. > > > If the plan is to go with a flag day by switching the default for > > time64, then I don't see how the LFS change can be decoupled, as that > > automatically will also forcibly enable LFS globally on glibc arches. > > I've also in general been worried about automatically enabling LFS w/o > > someone looking into each package, given the greater potential for > > data loss. :/ > > I think in the case of LFS-sensitive libraries that aren't part of the > dependency graph of packages affected by the time_t change, it's easy enough > to patch them to not turn on the LFS flag and avoid a transition. Just to try to understand whether we are on the same page. If these libraries have no time_t usage at all, then disabling time64 should then provoke no time_t issue and should stop implicitly enabling LFS. But if the library contains internal time_t usage that is not part of the exposed ABI, but part of its operation, then I'm not sure I see how we can patch them to disable LFS w/o at the same time losing time64 support (as the latter forces/requires the former). I'm not sure whether you are talking about the first or second case? And whether we have no libraries at all falling under the second case? > You raise a valid concern about data loss. However, I fail to see any way > that we can effectively mitigate this in advance - either now or by delaying > the time_t transition. I don't see any way to avoid this via automated > source analysis, so the only option (given that we can't avoid the time_t > transition forever) is to rebuild and then find out what breaks, which I > think is best done at the beginning of a release cycle - do you agree? To me that sounds like a rather scary and dangerous prospect, and I guess the main reason we have never considered doing this before. And I'm not sure all these cases can be discovered within a release cycle, even if this is done at the beginning of it. But that would certainly then become a blocker for the time64 transition. :/ Here again, I think if people in general are OK with the consequences, then I guess that would be OK, although TBH my ideal preference would be code review and enabling things manually (which is what I've done with packages I maintain, but yeah meh). The GR here also seems rather enticing I guess. Thanks, Guillem
