On Mon, 15 Aug 2022, Dan Čermák wrote:
Richard Biener <rguenther@suse.de> writes:
On Thu, 11 Aug 2022, Dan Čermák wrote:
Richard Biener <rguenther@suse.de> writes:
[..]
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.
To elaborate, the "system" would have a Provides: hw-x86_64-version = 3 for example and a package built for x86_64-v2 would then have a Requires: hw-x86_64-version >= 2. The Provides would be magically added upon install time somehow (thus "system provides").
You will not get around adding some logic to rpm itself, because you can unplug your harddrive and put it into a new PC or deploy a base image to a bunch of new PCs. Then the base package that provides your hardware capabilities is no longer valid, so I think this really must be generated by rpm itself[1]. But going via Provides/Requires does not sound like such a bad idea, as it could be used to add even more granularity, e.g. requiring only AVX512 or FMA3.
Not that this will help the unplug/plug (or CPU exchange to lower level) case - the system will not work, the only thing is that rpm might now see that the database is not in a consistent state anymore ;) And sure, explicit CPU feature requires/provides would be possible as well, but growing the list of Requires comes at a cost so I stuck with the architecture levels here (which also have the benefit to be comparable with not just equality). But yes, if you for example do
gcc -S t.c -v
you can see that GCC internally (on x86) does /usr/lib64/gcc/x86_64-suse-linux/7/cc1 -quiet -v t.c -march=haswell -mmmx -mno-3dnow -msse -msse2 -msse3 -mssse3 -mno-sse4a -mcx16 -msahf -mmovbe -maes -mno-sha -mpclmul -mpopcnt -mabm -mno-lwp -mfma -mno-fma4 -mno-xop -mbmi -mno-sgx -mbmi2 -mno-tbm -mavx -mavx2 -msse4.2 -msse4.1 -mlzcnt -mno-rtm -mno-hle -mrdrnd -mf16c -mfsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -mxsave -mxsaveopt -mno-avx512f -mno-avx512er -mno-avx512cd -mno-avx512pf -mno-prefetchwt1 -mno-clflushopt -mno-xsavec -mno-xsaves -mno-avx512dq -mno-avx512bw -mno-avx512vl -mno-avx512ifma -mno-avx512vbmi -mno-avx5124fmaps -mno-avx5124vnniw -mno-clwb -mno-mwaitx -mno-clzero -mno-pku -mno-rdpid --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=10240 -mtune=haswell -quiet -dumpbase t.c -auxbase t -version -o t.s so you "nicely" have a set of (possibly!) used CPU extensions available. It might be possible to auto-prune the list by scanning the binary for used instructions, OTOH if it includes a JIT that happily produces them that wouldn't work. Richard. -- Richard Biener <rguenther@suse.de> SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg, Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman; HRB 36809 (AG Nuernberg)