Hi! On Tue, 2024-02-06 at 15:42:33 +0100, Helmut Grohne wrote: > On Tue, Feb 06, 2024 at 11:34:07AM +0100, Adrien Nader wrote: > > Providing two APIs makes me quite uneasy due to having core components > > that would behave differently from the rest of the distribution. It > > sounds like something that will come back to bite for a long time. > > Can you elaborate?
Yes, I'm not sure I understand either. This is what symbol versioning makes possible, even providing different variants for the same symbol, see for example glibc or libbsd. In any case, if going the bi-ABI path, I think upstream should get involved, and the shape of this decided with them. In addition the library should also be built with LFS by the upstream build system, which it does not currently, to control its ABI. > Keep in mind that for all the 64bit architectures, there is no abi > difference as the symbol is only added for those architectures, that > currently use a 32bit ino_t. > > I checked on codesearch.d.n and there are very few users on this API; > > actually, none I think. Per > > https://codesearch.debian.net/search?q=matchpathcon_filespec_add&literal=1&perpkg=1 > > - box64 mentions that API but the "code" is commented-out, > > - busybox uses it in the "setfiles" applet which isn't built, > > - android-platform-external-libselinux has it in headers but also has > > its own implementation > > > > That should hopefully give more freedom although I'm not sure what would > > be the preferred route. > > And here you are arguing that there are no practical users of the added > symbol, so with luck, we'd be adding an unused symbol on armhf. With bad > luck, we'd have some users and for those users we'd be ABI-incompatible > with the rest of the world on armhf. I think there are only three ways to go about this, excluding the t64 attempt: 1) Build the library with LFS unconditionally (except on i386). As there are no users in Debian, this would not break there, but would break for any external packages and locally unpackaged users of the library. 2) Bump the SONAME, ideally coordinate with upstream or alternatively with a Debian specific one. This does not break locally built packages nor locally unpackaged code linking against the library. 3) Build the library with LFS support (everywhere including i386), and on systems w/o built-in LFS, make the old symbol use 32-bit ino_t, and add a new symbol that uses 64-bit ino_t. This preserves the ABI, for external packages and locally unpackaged code linking against the library. I think the three options would cause no upgrade issues, as they include either no SONAME bump (option 1 and 3), or an actual SONAME bump (option 2) with no file conflicts involved. Personally I'd like to be able to cleanly and safely build dpkg with time64 everywhere (including i386, otherwise the port will not be even installable), so my preference is for options that make that possible (2 and 3), and from those the one with best backwards compatibility with was the main concern for excluding i386 from the time64 transition would be option 3. So I think that would be the preferred option here. If you'd like assistance with trying to get a proposal for 3 to present upstream I could look into that. But I think they should be involved early on to see what they'd like to see and what they might outright reject. Thanks, Guillem
