On Fri, Dec 29, 2023 at 12:23:23PM -0000, Jonny Heggheim wrote: > How much waste is it to recompile all the packages? > > The whole proposal sounds like a big hack from beginning to the end. > Fragile setup with $PATH, complicated SPEC files, complicate the %build part.
I disagree that the setup of $PATH is fragile. We have clean mechanisms to set it, and if those mechanisms are broken somewhere, fixing them is something that we should do anyway, making the whole system better. The spec files will be more complicated, that is true. But I very much prefer a bit of complexity in a small set of packages than a "clean" solution that requires significant resource investment from releng and other places. At this point we don't even know if the whole thing will deliver the benefits that are expected. Doing the maximalist solution right now would be putting the cart before the horse. > In order to reduce build time that have not been quantified. Building packages with a different set of flags would be equivalent in terms of resource consumption to an additional architecture. We currently have x86_64, arm64, s390x, ppc64el (*), so a new microarchitecture variant would be ~25% more cost (for archful packages). But building packages is just one thing. Those packages would need to be distributed, causing additional load on mirrors and archives. Our mirrors would not be keen on seeing this increase. And then there's a question of how those packages would be consumed: firstly, the installer would need to be modified to pick the variant at installation time, and secondly, such an installation could never be used with a different CPU, the initial choice would be locked in. The benchmarks that were linked in the Change Propoposal show that it's a small minority of packages that show potential gains. I really don't expect that we'll end up with more than a few dozen packages where this turns out to be useful. Doing that within the existing architecture is much much cheaper than adding a new architecture variant. The proposed scheme is also more flexible: for example, x86-64-v3 may be great for some cryptotools, but v4 might be required to gain a good result for some codecs. Adding _multiple_ separate architectures is out of the question, but having some packages with two, three, or even four microarchitecture subpackages is no biggie. Zbyszek -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
