Re: 64-bit time_t: package lists, counts du jour, dd-list for NMUs
On 2024-01-22, Simon McVittie wrote: > Unfortunately, perhaps because common build systems like Autotools, > Meson and CMake make it awkward to use non-numeric SONAME suffixes, With CMake it is actually quite simple. Even to a point where it is easy to get wrong: add_library(Foo SHARED foo.cpp) set_target_properties(Foo PROPERTIES VERSION 1vorlon.0.0 SOVERSION 1smcv) $ objdump -x libFoo.so | grep SONAME SONAME libFoo.so.1smcv ls: libFoo.so -> libFoo.so.1smcv libFoo.so.1smcv -> libFoo.so.1vorlon.0.0 libFoo.so.1vorlon.0.0 /Sune
Re: 64-bit time_t: package lists, counts du jour, dd-list for NMUs
On Mon, 22 Jan 2024 at 05:31:45 -0800, Steve Langasek wrote: > Others in this list have package names I don't understand, such as a 'd' > suffix that doesn't correspond to anything in the soname I believe this is conventionally used to mean "this is a Debian-specific SONAME that intentionally differs from upstream's ABI", either because the upstream project doesn't support building a shared library at all, the upstream builds a shared library but breaks the ABI without bumping the SONAME (and resists attempts to fix this upstream), or there is ABI added/removed in Debian delta. Ideally this would be addressed with an "upstream first" approach, or failing that, it should genuinely be part of the SONAME, as in e.g. libstemmer0d (which is static-only upstream, and Debian patches the build system to produce a libstemmer.so.0d shared library) and libleveldb1d (I haven't checked the history, but presumably it's similar). For packages in the libstemmer0d situation, since the ABI is Debian-specific *anyway*, the right route is perhaps to bump the SONAME to libstemmer.so.0d1 or libstemmer.so.1d and handle it like a normal transition? Unfortunately, perhaps because common build systems like Autotools, Meson and CMake make it awkward to use non-numeric SONAME suffixes, there are also libraries that use the 0d suffix but *don't* include the "d" in the SONAME, for example libcdd0d (libcdd.so.0). Looking at the cddlib (libcdd0d) changelog, it seems that 0d is a little misleading in this case, because the ABI is *not* Debian-specific: * Renamed libcdd0 to libcdd0d. The ABI changed since the last package, but upstream started using the SONAME 0 now. Since the package is not widely used, changing the package name, but not the SONAME, is enough. For the libcdd0d situation, it's "the same shape" as a toolchain ABI suffix like v5 or t64, so a rename to libcdd0t64 would probably be right (if this package is affected by 64-bit time_t, which I haven't checked). Another convention that is sometimes used if upstream doesn't really handle ABI breaks the way we would want, and there is a manageably small number of dependent packages in Debian, is to package the library libfoo.so.0 as libfoo0, then libfoo0a, libfoo0b, and so on. This is difficult to distinguish from the "0d" conventions above, if the ABI happens to have been broken exactly 4 times. Examples of this include libharfbuzz0b, libgjs0g, libcryptui0a. Again, for the libharfbuzz0b case, it's "the same shape" as a toolchain ABI suffix like v5 or t64, so a rename to libharfbuzz0t64 would probably be right (if this package is affected by time_t at all). > or libcoin80c Unfortunately the changelog just says "Renamed package dropping v5 suffix to c", without explaining why. Since this used libcoin80v5 for the libstdc++ v5 transition, I would guess that libcoin80t64 could be the right name for it now? But its maintainers would know better. smcv
Re: 64-bit time_t: package lists, counts du jour, dd-list for NMUs
In exercising scripts for the mass NMUs in a dry run, I've run into another little snag. $ grep -vEc '[0-9](c102|c2|g|ldbl|v5)?$' reports/runtime-libs 234 $ The package rename handling assumes that the affected runtime library packages have names matching a certain pattern (ends in a digit, plus a possible previous ABI qualifier). But 234 of the library patches don't match this pattern; some don't correspond to library sonames at all. Right off the bat, the first of these is 389-ds-base-libs. I don't want to rename it to '389-ds-base-libst64'. Also it turns out that there are no reverse-dependencies of this lib package. So I will omit this package from the transition. Others in this list have package names I don't understand, such as a 'd' suffix that doesn't correspond to anything in the soname, or libcoin80c. libdmtx0b and libvibrant6b at least have explanations in the changelog. So I guess I'll work on fleshing out a rename map for these. On Sun, Jan 21, 2024 at 12:57:17AM -0800, Steve Langasek wrote: > Hello, > > Here is an updated analysis of the transition. This is based on a full > rerun on Debian unstable as of 2024-01-17 and includes a number of > incremental fixes reducing the number of libraries to be transitioned. > Though this is not particularly significant; the number of source packages > to be NMUed drops from 1197+51=1248 to 1192+50=1242, and the number of > source packages to be binNMUed drops from 5442+170=5610 to 5415+170=5585. > > It also picks up a small number of source packages (5) that are new to > unstable since last month. I have no strong opinion about forcing a package > name change for these, since they likely don't have any reverse-dependencies > yet with a significant install base on 32-bit archs; but by default they're > included. > > > Output files from the new analysis can be found here: > > https://adrien.dcln.fr/misc/armhf-time_t/2023-12-18/ > > I am not making the same mistake as before and attempting to attach all of > the various supplementary files, thus hitting email size limits. Instead, I > have pushed them all to: > > https://people.canonical.com/~vorlon/armhf-time_t/ > > > You may have noticed that it is now past the original proposed date of > 2024-01-18. This was a knowingly aggressive target date on which to try to > converge; there are still discussion subthreads in flight on debian-devel > that I want to make sure settle out before we proceed, and also Guillem let > me know there was a dpkg upload planned that would conflict, pushing this > back to Monday, 22 Jan at minimum. Based on capacity and availability, I > would like to now start uploads to experimental this Friday, 26 Jan. > > I do not know how long it will take to build all 1200+ source packages and > upload them. I assume it will take a few days at least. Once the > transition has started, I will post again to debian-devel with projections > of when we might expect to start landing changes in unstable. > > Attached is the current dd-list for the packages that would have sourceful > NMUs. -- 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
