On Sat, 18 Mar 2023 at 14:46:47 +0100, Andrea Bolognani wrote:
> In other words, upstream developers have retroactively added symbols
> (fuse_new_31) to existing symbol groups (FUSE_3.1).
...
> really this looks like an upstream
> bug in my opinion: even if the function was present in the source
> code all the way back in 3.1, it's only publicly exported starting
> with 3.13, and so exposing it as fuse_new_31@FUSE_3.13 would have
> been the correct way to go about it IMO.
I agree that this was incorrect, but now that several released libfuse
versions have had this bug, it is part of the ABI. In the absence of a
time machine, upstream cannot go back and correct it.
> I believe it should be possible to work around this in Debian by
> adding an entry like
>
> fuse_new_31@FUSE_3.1 3.13.0
>
> to debian/libfuse3-3.symbols
Since we don't have a time machine, I think this would be the
correct answer to this bug. That would result in packages like
libvirt-daemon-driver-lxc generating correct dependencies next time they
are rebuilt.
On Wed, 13 Mar 2024 at 01:05:40 +0100, Bernd Schubert wrote:
> Would it help to move that symbol to FUSE_3.13 in the version script
> (for example in libfuse-3.17?)?
No, please don't do that: that would make the library as shipped by
Debian permanently incompatible with one built from upstream source.
smcv
