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

[Steve Langasek]

On Wed, Feb 07, 2024 at 09:06:58AM +0100, Helmut Grohne wrote:
> On Wed, Feb 07, 2024 at 04:32:45AM +0100, Guillem Jover wrote:
> > 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.

> I think symbol versioning is subtly different and glibc does not use
> symbol versioning for e.g. gettimeofday selection. With symbol
> versioning, you select a default version at release time and stick to
> it. In other words, building against the updated libselinux does not
> allow you to use the older 32bit variant of the symbol even if you opt
> out of lfs and time64 and you always get the 64bit symbol. What glibc
> does is a little more fancy than my simplistic #define in that it uses
> asm("name") instead. Still this approach allows for selecting which
> symbol is being used via macros (e.g. _FILE_OFFSET_BITS). Please correct
> me if I am misrepresenting this as my experience with symbol versioning
> is fairly limited.

Agreed.  libselinux as it happens does use a symbol version map so there is
symbol versioning involved in some sense? but not the sense you really mean.

(We could make the symbol map expose the two different function variants
under the same name but different symbols; that's fine but I'll leave that
for upstream to decide.)

> > 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.

> I agree that involving upstream is a good idea and my understanding is
> that someone from Canonical is doing that already, which is why the
> schedule was delayed.

Well, "already" is not exactly correct, but the need to resolve this
critical showstopper bug in libselinux before making changes to the
toolchain behavior in unstable and breaking the world has affected the
timeline, yes.

I now have a tested patch that I've raised as an MP in salsa:

  https://salsa.debian.org/selinux-team/libselinux/-/merge_requests/9

I welcome review from the Debian libselinux maintainers prior to opening a
discussion with upstream.  (Which I will plan to do sometime Thursday
US/Pacific)

-- 
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/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/selinux-devel/attachments/20240214/0daf3688/attachment.sig>