Replying separately to issues unrelated to libselinux, dropping the bug from cc: and picking a possibly better subject.
First, I want to double check here: the libselinux bug was identified as a showstopper because removal of the file from disk even briefly breaks dpkg itself, making recovery impossible. The other libraries mentioned in this thread, though transitively essential or at least Priority: required, are not dependencies of apt and so do not have this impact. So is the consensus that these other libraries also all need solutions that avoid package renames? Of course, we should look for the best possible technical solution here, but not at the cost of indefinitely dragging out the transition for issues that aren't showstoppers. On Wed, Feb 07, 2024 at 09:06:58AM +0100, Helmut Grohne wrote: > pam seems difficult: > | extern time_t pam_misc_conv_warn_time; /* time that we should warn user */ > | extern time_t pam_misc_conv_die_time; /* cut-off time for input */ > We cannot symbol-version these in a reasonable way. All we could do is > ask upstream for a real soname bump. We have a slight advantage here: On > little endian (such as armhf), we can extend this to 64bit and 32bit > accesses will continue to work for small values. However, doing this to > m68k would break horribly. I also couldn't find any in-Debian users of > these symbols (super merely vendors pam source), so just bumping it and > accepting breakage (Guillems option 1) might be worth a go? Since these are basically part of a 30-year-old spec that predates Linux PAM and there doesn't seem to really be any real-world use of these, IF we decide that a package rename for libpam0g is unacceptable, then I think option 1 is ok. The impact would be corner case runtime misbehavior of applications depending on being able so set a non-default timeout (the default value here is 0), not application crashes. We could potentially "clean" this up after the fact as well by detecting cases where the low 32-bits are 0 on big-endian archs and word-swap, which would keep those hypothetical applications working as-is without recompile until 2038. > For libaudit1, I fail to understand why we bump it at all. Both reports > look fine to me: > https://adrien.dcln.fr/misc/armhf-time_t/2024-02-01T09:53:00/compat_reports/libaudit-dev/base_to_lfs/compat_report.html > https://adrien.dcln.fr/misc/armhf-time_t/2024-02-01T09:53:00/compat_reports/libaudit-dev/lfs_to_time_t/compat_report.html > This does not extend to libauparse0 where the report gives a reason, but > libaudit1 is the one that interacts with /usr-move and libauparse0 not, > so can we skip the dance for libaudit1? Thanks. The issue is that in cases of a source package with multiple header packages and multiple runtime packages, there is no way to consistently and reliably map between the two, so we conservatively assume that any -dev package in the source package whose ABI is affected impacts all runtime libraries. (In this specific case there's enough information that we *could* programmatically identify that libaudit-dev depends libaudit1 but not libauparse0, libauparse-dev depends libauparse0 and not libaudit1, and the dev packages do not depend on one another; however, this was not implemented.) Since eyeballing this clearly shows that only libauparse0 has an impacted ABI, I will do a follow-up upload to experimental correcting this. > For libtirpc, it is only about rpcb_gettime, which returns time via a > time_t* and can indicate success/failure via return. It seems fairly > simple to implement ABI duality here and libtirpc already does symbol > versioning. Maybe we can also approach upstream about this? This is the only mention of libtirpc in this thread; it is not Essential: yes or Priority: required. The bug you filed about inadequate mitigation in experimental is closed. So I'm not sure why this is on the list here, unless your concern is that we should aim to avoid ALL such maintainer script mitigations for file moves from / to /usr and have a blanket ban on the renames? > For libfuse2, I think the ABI analysis is broken. The base-to-lfs report > supposedly is ok > https://adrien.dcln.fr/misc/armhf-time_t/2024-02-01T09:53:00/compat_reports/libfuse-dev/base_to_lfs/compat_report.html > and then going lfs-to-time changes ino_t > https://adrien.dcln.fr/misc/armhf-time_t/2024-02-01T09:53:00/compat_reports/libfuse-dev/lfs_to_time_t/compat_report.html > while I would have expected ino_t to change with lfs already. Are we > sure about this? In any case, this is more of an academic question as > adding ABI-duality would be more involved here. Are we *sure* about it, no. But I'm not sure it's worth the effort to get a definitive answer here. libfuse2 should be deprecated in favor of libfuse3 and if there's pushback I'd rather just allow it to be broken for 64-bit time_t and use this as a forcing factor to complete the transition, rather than putting effort into fixing libfuse2. (the number of reverse-dependencies is unfortunately still quite large.) > Moreover, I don't see > any ACC report for libfuse3-dev. Did that fail to analyze? Yes: https://adrien.dcln.fr/misc/armhf-time_t/2024-02-09T15%3A12%3A00/logs/libfuse3-dev/time_t/log.txt looks like a bug in the quirking script. The same bug appears to be present for libhiredis-dev. > Also when looking into effort, please keep in mind that for every case > mentioned in this email, we're looking into adding a protective > diversion due to the package rename without so rename and then in forky > we'll have to clean up all those diversions, and in forky+1 we'll have > to delete the cleanup code, so while investing more now may seem more > expensive, it saves later. I think the cost of chasing upstreams about soname bumps and dual-abi'ing libraries swamps any savings for the maintainers having to do lazy cleanup of some lingering diversions. Thanks, -- 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/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: PGP signature
