On Sat, Jan 18, 2025 at 04:33:17PM +0100, Miroslav Suchý wrote: > Dne 18. 01. 25 v 11:01 dop. Mattia Verga via devel napsal(a): > > I think some of the build failures are due to building things out of > > sequence. > > I agree with Fabio in this thread, that it is (should not be) the case. Also agreed. > > 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: > > As one of the Mock developer, I have seen several people trying to create > script that build-order packages. All of them failed. Including me. > > There are lots of traps: > > - Some dependencies are generated only during the build E.g., https://fedoraproject.org/wiki/Changes/DynamicBuildRequires > > - Some **names** of packages are generated only during the build. E.g. SoftwareCollections (not relevant for Fedora itself). > > - It is hard to parse Requires from SRC.RPM because of %if condition and > other macros. Basically you have to that in correct build environment only. Yeah, the old thing of us only having one src.rpm, but actually there's one for each arch. > > - it is hard to evaluate the macros. You have to be in the build enviroment > of the target platform with all installed macros as SPEC files heavily used > various srpm-macros as deps and even including their own macros as SOURCEX. > > - did I mention %bootstrap macro? Additionally to all the other reasons this would be difficult: * The current mass rebuild does not update the buildroot. It just builds into a side tag using the existing rawhide buildroot. If you wanted to rebuild later things with the eariler things you would need to update the buildroot with them. If we regenerate it after every build it would slow things down to a crawl. If we did it after every 'group' it would not slow down as much, but... what happenes if one of these updates breaks the buildroot? Someone(s) would have to keep careful watch and fix things. Or if it was done in a seperate buildroot, rawhide wouldn't be broken, but... maintainers push updates even during the mass rebuild, so how do you merge things? If the newer rawhide package is retained, then you are merging things built against the older one in the mass rebuild. * In general it would probibly mean you would need to forbid other updates while it's running, as updates could mess up the dependencies and in progress 'loops' So, yeah, I don't think it's tenable... we could perhaps look at adjusting packages to make this more possible/a goal down the road if thats something we want to do. > The only way that works, is what mockchain does: build the packages in > random order. if any fails, repeat while at least one package in the loop > succeed. So, this is an interesting idea. Perhaps we should start doing this for mass rebuilds? It should be pretty easy to wait for it to finish, gather all the failed ones and resubmit them, see if any worked, if so, resubmit again. This would of course make things take longer and would be a waste of cpu/etc, and it would generate more notification noise to maintainers, but it might save work in the end? Most of the failing packages would likely fail pretty fast too. kevin
Attachment:
signature.asc
Description: PGP signature
-- _______________________________________________ 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
