[DSE-Dev] Bug#1063329: libselinux1t64: breaks system in upgrade from unstable

[Guillem Jover]

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