Re: libselinux1t64 (et al): breaks system in upgrade from unstable
Hi,
On Thu, Feb 15, 2024, Steve Langasek wrote:
> > 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.)
fuse.pc uses -D_FILE_OFFSET_BITS=64 and I see no reason it would apply
only when doing two of the ABI dumps and not the third one.
Abi-compliance-checker reports type changes but not size changes so I'm
inclined to think it's just hitting different paths in the glibc headers
and the type name is different (which makes sense since there is no
non-lfs in time64).
> > 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
The analysis is fixed now and no ABI change has been detected (for LFS
or for time_t).
> looks like a bug in the quirking script. The same bug appears to be present
> for libhiredis-dev.
Analysis is fixed too and no ABI change has been detected for it either.
I'm not publishing consolidated results yet; unless there is a need
before, I'll do it on Friday.
--
Adrien
Reply to: