On Fri, Dec 29, 2023 at 03:20:45PM -0600, Chris Adams wrote: > Once upon a time, Zbigniew Jędrzejewski-Szmek <zbys...@in.waw.pl> said: > > 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. > > You're adding binaries, so you're either increasing the size of existing > packages or adding alternate packages. The size increase will be there > either way; the difference is that with separate packages, not everybody > will be downloading all the content (so easier on the mirrors than just > bigger packages containing multiple binaries). > > So if distribution is a concern, separate packages is a plus, not a > minus.
We don't have a mechanism in dnf/rpm to mix & match, i.e. to select from one microarchitecture if available and from a different one otherwise. So if we were to provide e.g. a -v2 variant, then it'd have to provide _all_ packages. In the proposed scheme, we only provide additional packages for select packages. > > 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. > > It's not like we haven't had this before. Yes, it was annoying, but it > wasn't THAT big of an issue. There is certainly more than one way to skin this particular cat. I don't expect most users to know which microarchitectures are supported by their CPU. We are always trying to make the installer as simple as possible so we shouldn't add a very complex technical question. One of the advantages of the proposed scheme is that we should be able to make it work transparently and automatically for the end users. I know that my approach is different then what other distros have tried: CentoOS/RHEL simply upgraded to a higher baseline and lost support for some CPUs, OpenSUSE/Ubuntu/Arch provide alternative repos which need to be explicitly selected by users. If the proposal gets accepted, we will be able to compare. 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
