Package: libselinux1t64
Replaces: libselinux1
Provides: libselinux1 (= 3.5-2.1~exp1)
Breaks: libselinux1 (<< 3.5-2.1~exp1)
Afaiui libselinux1t64 must not fullfill dpkg 1.22.4's dependency on "libselinux1 (>= 3.1~)". dpkg needs to be rebuilt and the rebuilt
version gets a dep on "libselinux1t64 (>= 3.5)".
Will ${t64:Provides} stop expanding to "libselinux1 = ${binary:Version
for real t64-builds? (The ones in experimental are not.) If that is case
this bug and this way of testing does not make sense.
An option I see here is to provide ABI-duality for libselinux:
-extern int matchpathcon_filespec_add(ino_t ino, int specind, const char *file);
+typedef unsigned long libselinux_ino_t;
+typedef uint64_t libselinux_ino64_t;
+extern int matchpathcon_filespec_add(libselinux_ino_t ino, int specind, const char *file);
+#if defined _FILE_OFFSET_BITS && _FILE_OFFSET_BITS == 64 && sizeof(unsigned long) < 8
+extern int matchpathcon_filespec_add64(libselinux_ino64_t ino, int specind, const char *file);and keeping this #define here instead of using internal in-glibc
+#define matchpathcon_filespec_add matchpathcon_filespec_add64
"Helmut" == Helmut Grohne <helmut@subdivi.de> writes:
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.
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.
forwarded -1 selinux@vger.kernel.orgBug #1063329 [libselinux1t64] libselinux1t64: breaks system in upgrade from unstable
Control: forwarded -1 selinux@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:
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)
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 297 |
Nodes: | 16 (2 / 14) |
Uptime: | 10:09:13 |
Calls: | 6,666 |
Files: | 12,213 |
Messages: | 5,336,333 |