On Mon, Jan 20, 2025 at 6:01 AM Vít Ondruch <vondr...@redhat.com> wrote:
> > Dne 18. 01. 25 v 11:01 Mattia Verga via devel napsal(a): > > I have an idea I'd like to hear you out on how to reduce failures on > > mass rebuilds. > > > > I think some of the build failures are due to building things out of > > sequence. I mean, package A buildrequires package B, but since the mass > > rebuild is performed (AFAIK) alphabetically, package B is rebuilt after, > > so package A rebuild may fail. > > > > The optimal solution would be to have some script that periodically > > creates a tree of buildrequires dependency for all Fedora packages... > > but that would require some work. So, I was just thinking, what about to > > set up a simple repository where we put some text files like: > > > > - tier1.txt: > > - libindi > > - kpmcore > > > > - tier2.txt: > > - indi-3rdparty-libraries > > > > (possibly a tier3.txt too) > > > > On mass rebuilds, all packages specified in tier1.txt are rebuilt first, > > then all packages in tier2.txt (and so on), then all other packages like > > the current mass rebuild does. > > In my example this would mean that the correct sequences on rebuild are > > maintained: > > > > - T1: libindi -> T2: indi-3rdparty-libraries -> mass rebuild: > > indi-3rdparty-drivers (and kstars, stellarium, etc.) > > - T1: kpmcore -> mass rebuild: kde-partitionmanager > > > > I think this could be a simple and quick solution to maintain build > > chains on mass rebuilds. Thoughts? > > 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. > > While I am not sure this is strictly needed for mass rebuild, having > build order is generally useful. In modular days, we were able to > specify the build order: > > > https://docs.fedoraproject.org/en-US/modularity/building-modules/fedora/defining-modules/#_building_in_a_specific_order_optional > > I also know the Mikolaj has some tooling for defining build order, which > he use for Maven rebuilds: > > https://github.com/mizdebsk/mbici-workflow/?tab=readme-ov-file#build-plan > > While we never had any metadata, build order was also required for > Software Collections for those who remember. > > Just FTR, working on Ruby on Rails 8 for Fedora, possibility to have > build order specified would help with the rebuilds as well as bootstraps. > Build order lists certainly would be advantageous for bootstrapping and handling major uplifts (such as major language upgrades), but those are very different user stories than the mass rebuild. In general, I think it's probably implausible for us to design a common tool that will work in all cases, though. It's probably best for the people who maintain those big situations to keep their own domain-specific scripts around for how to build their stuff in a side-tag.
-- _______________________________________________ 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
