On Tue, May 16, 2023 at 09:31:05PM -0700, Russ Allbery wrote: > Steve Langasek <vor...@debian.org> writes:
> > * Largely via NMU, add a “t64” suffix to the name of runtime library > > packages whose ABI changes on rebuild with the above flags. If an > > affected library already has a different suffix (c102, c2, ldbl, g…), drop > > it at this time. > This is possibly me being too fiddly (and also I'm not 100% sure that I'll > get to this in time), but ideally I'd like to do an upstream SONAME > transition for one of my shared libraries (and probably will go ahead and > change it for i386 as well, since I'm dubious of the need to run old > binaries with new libraries in this specific case). > What's the best way for me to do that such that I won't interfere with the > more automated general transition? Will you somehow automatically detect > packages that have already been transitioned? Or should I wait until the > package has been automatically transitioned and *then* do an upstream > transition? It would be possible to automatically detect that a package has been transitioned, by a combination of: - checking the date of the last source upload (if it's after dpkg-buildflags defaults have changed, or not) - inspecting the symbols referenced from glibc by the library to confirm whether it includes any 64-bit time_t variants It's doable, but I think it would be rather a lot of work for an edge case where the maintainers could simply revert the NMU if they determined it was unnecessary. > > Your thoughts? > The one additional wrinkle is that there are packages that, due to > historical error or unfortunate design choices, have on-disk data files > that also encode the width of time_t. (I know of inn2, which is partly my > fault, but presumably there are more.) Rebuilding that package with the > 64-bit time_t flags would essentially introduce an RC bug (data loss) > because it will treat its existing data files as corrupt. Do you have any > idea how to deal with this case? > (The LFS transition was kind of a mess and essentially required users to > do manual data migration. This time around, maybe we'll manage to write a > conversion program in time.) INN is called out on https://wiki.debian.org/ReleaseGoals/64bit-time. Unfortunately, I know it depends on at least one library package that has an ABI change (libpam0g), though it happens that only libpam_misc, which INN doesn't link to, has an ABI change; so we could adjust that source package to not do the time_t switch if that's the only blocker. But it also build-depends on libkrb5-dev and libssl-dev, both of which are affected by time_t. So maybe the best workaround in the short term, if there's no immediate data migration path, would be to change the inn2 source to use unsigned long in place of time_t in the data format? I don't have any inkling how widespread this problem will be nor do I see any path towards automatically detecting such issues (a codesearch on time_t would return far too many false-positives to be useful). It really depends on maintainers knowing what the code in their packages does. -- 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
