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

[Steve Langasek]

Control: forwarded -1 selinux at vger.kernel.org

Patch now forwarded upstream for review.

https://lore.kernel.org/selinux/Zc6tzKPsYZRICHya@homer.dodds.net/T/#t



On Wed, Feb 14, 2024 at 11:25:26PM -0800, Steve Langasek wrote:
> 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

-- 
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/20240215/ad3497f4/attachment.sig>