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.
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.
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
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.
-
Daniel P. Berrangé -
Richard W.M. Jones