On Tue, 21 Jan 2025 at 13:13, Stephen Gallagher <sgall...@redhat.com> wrote:
> > > Well, first of all, maintaining such a tiered list manually is a realistic > impossibility, given the number of packages in Fedora. In Fedora ELN we > have a *very* tiny list of things we build exceptionally: all of them are > in the build toolchain. > > Second, when doing a mass-rebuild, ordering shouldn't generally be (as > much of) a problem. The main reason that package ordering is necessary is > for dependencies. In the case of a mass-rebuild, in nearly all cases you > should be able to assume that if the package built previously, then it > should be able to rebuild with the packages currently in the buildroot. > Now, this isn't always true because sometimes a newer version of a build > dependency introduces a regression or other compatibility issue, but in > that case there's nothing that can be done by reordering the build: you > need to patch one or the other to fix the incompatibility. That's one of > the main purposes of running a mass rebuild in the first place: it's the > primary warning system we have for discovering that a package that built > previously has stopped being buildable in the current environment. > > I think the reason people think that the lack of ordering is that it really relies on various "toolchains" having gotten all their changes done before the mass rebuild happens. If something were to cause a new compiler or static library to get built in the mass rebuild, then every package built will be using the old one BUT every package built after the mass merge would be built with the new tools. Or if the new compiler lands right before the new build, various code may not compile because most programmers were not aware that the defaults now needed to use a newer standard and various code is now 'broken'. When things like the above happen in a mass rebuild, we get the 'we should have an ordered rebuild' thread going. Having been someone who proposed this in the past, it seems like a quick fix in which we use 'computers' to do the messy parts and we won't have to worry about things. The actual implementation is another matter and quickly explodes into complexity where you keep throwing duct tape to try and get that last 90% solved but find each fix broke some other 80%. I really don't think that outside of a *cough* core *cough* set of packages it is possible to actually accomplish without full time people constantly reworking the graphs every couple of weeks ( I am looking at you go but AI python is not much better). Anyway.. at this point I don't think you could make 'build-order' work in Fedora without a deep change in culture, packaging system and developer mindset. -- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren
-- _______________________________________________ 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
