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
Can you please provide reproducer and ideally also debugdata provided by "dnf install --debugsolver <package>"?
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 ~~~
Created attachment 1712368 [details] debugdata The repos are huge, so I omitted them.
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.
(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.
I have opened upstream RPM ticket: https://github.com/rpm-software-management/rpm/issues/1344
This bug appears to have been reported against 'rawhide' during the Fedora 34 development cycle. Changing version to 34.
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.
This is still valid request, although there were provided some workarounds in the RPM upstream ticket referenced above
This is an upstream matter and an upstream ticket already exists, closing.