fuse3 allows differing NVR subpackages to be installed

[Richard W.M. Jones]

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.

Is this a mistake or intentional for some reason?  I wasn't sure
whether to just fix this or file a bug.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top

[Richard W.M. Jones]

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.
>  
>  Is this a mistake or intentional for some reason?  I wasn't sure
>  whether to just fix this or file a bug. 
Any thoughts on this?  If you want I can just go ahead and fix this
for you.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v

[Daniel P. Berrangé]

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.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

[Richard W.M. Jones]

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