![](https://seccdn.libravatar.org/avatar/e6dc8afd12f42302ae7b5ea72e4dd686.jpg?s=120&d=mm&r=g)
Richard Biener <rguenther@suse.de> writes:
On Thu, 11 Aug 2022, Dan Čermák wrote:
Larry Len Rainey <llrainey15@gmail.com> writes:
Can anyone prove or disprove that the kernel has to be V3 for things like ImageMagic to run if it is complied V3?
No, the kernel does not have to be compiled with x86_64 v3.
I could see a ImageMagic-V3 as an option for those with hardware that can take advantage of it and just plain ImageMagic for those that cannot.
Yes, that's what I'd like to see as well, but currently rpm does not support this natively (it could be worked around via different multiple repositories though, but I'd like a proper solution to be honest).
The first and foremost rpm feature missing is a standard way to specify a minimum required set of HW capabilities a package requires. Currently the rpm meta includes the architecture, so one "obvious" way would be to simply add additional architectures.
Yes, that would be preferable. Unfortunately this requires a complete revamp of the way rpm handles architectures.
But then rpm itself doesn't do any magic and will happily install even arm architecture packages to your x86_64 system IIRC.
Yes, this part needs to get covered by the "upper layer" of the package management, i.e. zypper or dnf.
There are already packages existing in our x86_64 repository that will not run correctly on original x86_64 hardware but SIGILL. Unfortunately there's currently no way to annotate those appropriately and prevent them from installing on systems not capable enough.
The suggestion of multiple repositories is just one possible technical implementation of such annotation, using system provides and package requires would be another (then with the technical issue of having multiple same named but different filenamed packages in the same repository?).
[OT] Why requires though? I don't think it's a good idea to explicitly require a library with a certain instruction set. Provides on the other hand would be a workaround, but I really think that architectures are the proper way how this should be handled. Cheers, Dan -- Dan Čermák <dcermak@suse.com> Software Engineer Development tools SUSE Software Solutions Germany GmbH Frankenstrasse 146 90461 Nürnberg Germany (HRB 36809, AG Nürnberg) Managing Director/Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman