On Mon, Jun 26, 2023 at 12:07:35PM +0100, Daniel P. Berrangé wrote: > On Wed, Jun 21, 2023 at 10:58:28PM +0100, Richard W.M. Jones wrote: > > It's possible to create this situation: > > > > fuse3-libs-3.13.1-1.fc38.x86_64 > > fuse3-devel-3.13.1-1.fc38.x86_64 > > fuse3-3.14.1-1.fc39.x86_64 > > > > fuse3-devel correctly requires the exact version of fuse3-libs. > > However there doesn't seem to be any similar requirement connecting > > fuse3 & fuse3-libs. > > fuse3 will get the automatic elf dependancy, but that's merely > tied to the soname by default. If libfuse had symbol versioning > you would get much more fine grained dependencies that might > block it, but it doesnt use versioning. > > > Is this a mistake or intentional for some reason? I wasn't sure > > whether to just fix this or file a bug. > > When a package has a binary that depends on a 3rd party library > I think its reasonable to just rely on the auto-generated deps > by default. You can assume the binary will be expecting to work > aganist a wide variety of versions of the 3rd party library and > has probably been tested as such to some extent. > > When a package has a binary that depends on a library in its > own sub-pacakge, then I tend to think the full NEVR dep should > be present, as you can assume upstream will have probably never > done any testing of mismatched versions. Forcing an exact match > is the safe option to maximise reliablity. > > So even if the fuse/fuse-libs mis-match is harmless today, I > would still suggest preventing it via an explicit dep. It's actually not harmless because the older fuse3-devel has a broken header file (https://bugzilla.redhat.com/2187249). I was very confused when upgrading fuse3 didn't fix the issue, hence my investigations. I'll fix this as you describe, thanks. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
