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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Reply via email to