Bug 1870275

Summary: Choose the right architecture for library dependencies
Product: [Fedora] Fedora Reporter: Vít Ondruch <vondruch>
Component: rpmAssignee: Packaging Maintenance Team <packaging-team-maint>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: medium    
Version: rawhideCC: dmach, igor.raits, jmracek, jrohel, mblaha, mhatina, mjw, packaging-team-maint, pkratoch, pmatilai, pmoravco, rpm-software-management, vmukhame
Target Milestone: ---Keywords: FutureFeature, Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-06-22 10:48:56 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
rubygem-ruby-vips.spec
none
debugdata none

Description Vít Ondruch 2020-08-19 15:58:10 UTC
Description of problem:
I am reviewing noarch package [1], which is using FFI to load some library. Trying to specify the library dependency such as `Requires: libvips.so.42`, when installing, it won't pick the target architecture, which should be x86_64 but installing i686 version instead. The problem is that for noarch package, I obviously cannot use `%{_isa}`, because it might have random value. But really, I don't understand why DNF does not pick the right architecture by itself? Of course, there is more packages providing `libvips.so.42`, but why not choose the best one?


Version-Release number of selected component (if applicable):
$ rpm -q dnf
dnf-4.2.23-1.fc33.noarch


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:
Package of improper architecture is installed as a dependency of noarch package.


Expected results:
Package of the target platform is installed as a dependency of noarch package.


Additional info:


[1]: https://bugzilla.redhat.com/show_bug.cgi?id=1870208

Comment 1 Pavla Kratochvilova 2020-08-24 13:37:24 UTC
Can you please provide reproducer and ideally also debugdata provided by "dnf install --debugsolver <package>"?

Comment 2 Vít Ondruch 2020-08-24 14:24:35 UTC
Created attachment 1712367 [details]
rubygem-ruby-vips.spec

This is the spec file I have used. I think there is nothing essential exept:

~~~
Requires: libvips.so.42
BuildArch: noarch
~~~

Comment 3 Vít Ondruch 2020-08-24 14:29:26 UTC
Created attachment 1712368 [details]
debugdata

The repos are huge, so I omitted them.

Comment 4 Pavla Kratochvilova 2020-08-26 11:57:08 UTC
Thanks for the provided information.

I just noticed that the problem is that "libvips.so.42" is actually only provided by vips-0:8.9.1-3.fc33.i686 (while vips.x86_64 provide libvips.so.42()(64bit)), so dnf must install the i686 packages to satisfy the dependencies. I suppose the "libvips.so.42" provide uses the "%{?_isa}" macro because it's not something that can be used in an arch-independent way, and for noarch package, another provide should be used - such as "Requires: vips". In any case, this doesn't seem like a dnf bug.

Comment 5 Vít Ondruch 2020-08-26 12:48:55 UTC
(In reply to Pavla Kratochvilova from comment #4)
> Thanks for the provided information.
> 
> I just noticed that the problem is that "libvips.so.42" is actually only
> provided by vips-0:8.9.1-3.fc33.i686 (while vips.x86_64 provide
> libvips.so.42()(64bit)), so dnf must install the i686 packages to satisfy
> the dependencies.

Oh my, you are right.

> I suppose the "libvips.so.42" provide uses the "%{?_isa}"
> macro

The provide is autogenerated by RPM generator, if I am not mistaken.

> because it's not something that can be used in an arch-independent
> way

And this is not completely right. Because rubygem-ffi is completely noarch package. It will work the same way with ruby.i686 as well as ruby.x86_64. The only thing it case is the "libvips.so.42" on the right place, which again is not specified by rubygem-ffi, but the system dynamic linker.

> and for noarch package, another provide should be used - such as
> "Requires: vips". In any case, this doesn't seem like a dnf bug.

Reassigning this to RPM. I think this is not right anymore and there should be generic, platform independent way, to require libraries by their name.

Comment 6 Vít Ondruch 2020-08-26 13:00:06 UTC
I have opened upstream RPM ticket:

https://github.com/rpm-software-management/rpm/issues/1344

Comment 7 Ben Cotton 2021-02-09 16:23:20 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle.
Changing version to 34.

Comment 8 Ben Cotton 2022-05-12 16:21:52 UTC
This message is a reminder that Fedora Linux 34 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '34'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 34 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Comment 9 Vít Ondruch 2022-05-16 12:28:36 UTC
This is still valid request, although there were provided some workarounds in the RPM upstream ticket referenced above

Comment 10 Panu Matilainen 2022-06-22 10:48:56 UTC
This is an upstream matter and an upstream ticket already exists, closing.