Re: fuse3 allows differing NVR subpackages to be installed
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