On Mon, Jan 13, 2025 at 12:10:44PM +0100, Jakub Jelinek wrote: > On Mon, Jan 13, 2025 at 09:11:35AM +0000, Zbigniew Jędrzejewski-Szmek wrote: > > First, this would require setting up the infrastructure to build and > > store and distribute multiple builds of a single version of a > > package. This is something that Fedora currently doesn't do, so it'd > > require changes to operations in mock, koji, bodhi, the CI, mirrors. > > We've been building packages like that for years, so I don't understand > how it would require changes. E.g. we had glibc.i386 and glibc.i686, when > glibc was built, it was built for both of those architectures and rpm/yum > chose the right one. I think this functionality stopped being used ages ago. At least a decade, but I think more. So it seems unlikely that it'd work out of the box. > > Second, dnf would need to learn about this and install the appropriate > > variant. > > I think it should have that support like it had for i686 vs. i386. That probably was yum. Then we had dnf4, and now we have dnf5. The folks who work on dnf and rpm should comment, but I expect that this functionality either has been removed or is completely bitrotted. > > Third, this choice would be "permanent", i.e. it would be done once at > > package installation time. If the user tries to boot the same image > > on different hardware, it might fail. This is inferior to the proposed > > approach where the choice is made at runtime. > > It is superior to that, because you don't have to pay the cost every time > you run the program. As discussed in the other part of the thread, the cost is negligible (~1 ms). This functionality would generally only be used for programs which are used for some significant computations, i.e. the start time is not much of an issue. > And if you really want to make it dynamic, why can't it be done through > $PATH? > Make sure something early in the sessions changes /usr/bin and perhaps > /usr/sbin in $PATH to > /usr/bin/glibc-hwcaps/x86-64-v3:/usr/bin/glibc-hwcaps/x86-64-v2:/usr/bin > or similar (depending on the available features). > This is similar to what the dynamic linker does for libraries... This was v1 of the proposal (https://fedoraproject.org/wiki/Changes/Optimized_Binaries_for_the_AMD64_Architecture). I think this would work OK on amd64, but v2, i.e. the current proposal, seems better. For example, while the initial plan is to only cover a few microarchitecture levels on amd64, the scheme can be easily extended for additional architecture variants. Some architectures have many more µarch levels. Having them all in $PATH would be annoying. Dynamic selection is more verstatile and flexible. Zbyszek -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
