On Wed, Mar 13, 2024 at 11:06:03AM +0000, Simon McVittie wrote: > 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.
Just for the record, I agree with everything Simon has written. -- Andrea Bolognani <e...@kiyuko.org> Resistance is futile, you will be garbage collected.
signature.asc
Description: PGP signature
