On Thu, Jun 08, 2023 at 04:06:08AM +0200, Guillem Jover wrote: > On Mon, 2023-05-22 at 18:17:44 -0700, Steve Langasek wrote:
> > 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. After thinking about it, I'd like to suggest the following approach. - dpkg with the new default behavior uploaded to experimental - libraries uploaded to experimental with the new package names (so, NEW processing gets done) and with a versioned build-dependency (easy to automate with sed on debian/control) - once all the libraries have cleared NEW, copy to unstable without dropping the versioned build-dependency; it will never be wrong, it will always at most be cruft that can be cleaned up lazily What do you think? > > > 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? Oh ok, I didn't catch that this is what you meant. But it's not clear to me what you mean by "not catch older affected versions" - why would it be wrong to Breaks/Replaces against non-existent, newer versions of an obsolete binary package name? It's not a difficult change to make, I just don't understand why it's important. > > > > 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? I was only thinking about the first case, I had not previously considered the second case. We should be able to determine fairly easily whether there are any in the second case; for all ELF binaries which are built from the same source package as an LFS-sensitive library, check whether they have references to any of the static list of symbols in glibc that are affected by time_t, and if they are, add them to the list of libraries to transition. I'll add this to the analysis in progress. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: PGP signature
