On Thu, Jun 20, 2024 at 7:30 AM Stephen Smoogen <ssmoogen@xxxxxxxxxx> wrote: > > On Wed, 19 Jun 2024 at 16:23, Fabio Valentini <decathorpe@xxxxxxxxx> wrote: > > > > On Wed, Jun 19, 2024 at 8:40 PM Peter Robinson <pbrobinson@xxxxxxxxx> wrote: > > > > > > On Wed, 19 Jun 2024 at 19:13, Dominik 'Rathann' Mierzejewski > > > <dominik@xxxxxxxxxxxxxx> wrote: > > > > > > > > On Wednesday, 19 June 2024 at 17:17, drago01 wrote: > > > > > [...] at some point we need to do the cut and not being held back by old > > > > > / ancient hardware forever. > > > > > > > > What do you mean by "being held back"? What's being prevented by not > > > > requiring x86-64-v2 for all packages while allowing few select ones to > > > > have higher arch requirements? And why do "we need to"? > > > > > > > > As Neal said, rpm allows building for target x86_64_v2, so... let's do > > > > that for those packages that require it? > > > > > > That may mean having two versions of the same package, one built > > > against v1 and one v2, you're then doubling the workload for a whole > > > lot of contributors for the sake of old hardware. > > > > > > We had the same discussions on i686 and the first few times it was > > > proposed it didn't get traction, but it eventually did. There was a > > > i686 SIG which ultimately went nowhere. > > > > > > To put this a different way, would you be prepared to do the work to > > > maintain the old v1 packages if maintainers don't want to maintain 2 > > > versions? > > > > IIUC this wouldn't require maintaining a separate package, but just > > adding x86_64-v2 as a separate build *target* for the same package. > > > > I don't think Peter meant additional packages since with the i686 it > didn't mean that. What it did mean was having to understand why two > architectures might do things differently and why bugs might show up > in one but not another. It also means that someone needs to > continually help release engineering make sure that the entire Fedora > build system (koji, composers, mock, createrepo, test tools, etc) make > sure the packages get built, and put into the repositories correctly, > that images get made correctly and such. This is continual work > because as has been seen any change to one tool in an update can make > the others stop working in weird ways. > > I am not saying this is a 'can't be done'.. but this is not Free Work. > The Fedora release engineering is pretty small, its physical and > compute resources are pretty confined. You can only keep so many > spinning plates going before they all come crashing down. That covers infra and rel-eng, but there's another aspect that is being underrepresented here as well. Testing. If you take a single SRPM and build it for v1 and v2, ideally you'd test it on v1 and v2 hardware. If you only test one target, then you're basically just assuming it works[1] on the other. In that scenario, whatever target is preferred for testing is the defacto default. I really don't think it's worth introducing more x86_64 targets across the entire package set. It doesn't scale on many levels. Pick your baseline according to whatever criteria you see best for the project and stick with it. josh [1] Quite frankly, I think the vast majority of the i686 builds fall into this "assume it works" category and it's a waste of resources to continue i686 on a large scale. I know "Steam games" is one of the leading use cases, and that seems like a great thing for a SIG to actually center around and continue focused package builds for. However, I've been ranting about i686 for years and have just accepted the fact that Fedora seems to want to pretend it's a worthwhile effort. -- _______________________________________________ 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
