On Sat, Jan 18, 2025 at 11:43:39AM +0100, Fabio Valentini wrote: > So if you see packages that *change* (either their dependencies, or > their contents - but ignoring codegen differences with new compiler > versions etc.) between the last build before the mass rebuild and the > build performed during the mass rebuild, that's a sign that the update > was not pushed "correctly" in the first place, IMO. Yeah, I think that people don't appreciate this fact. The whole discussion in the other part of the thread, about how to best record and process build dependencies, is … mostly pointless. I looked at some build failures in this mass rebuild, and _none_ of them are caused by missing dependencies. (And as you say, this should never happen, so this is the expected result.) Some were indeed caused by dependency problems, but it is a special case of the case you describe above: because of the sbin merge and the sysusers change, some packages are not installable. But such an issue is not something that is normally expected to part of the mass rebuild. Those packages are FTBFS, independently of the mass rebuild. If we're to optimize the mass rebuild, one thing that we could handle better, I think, is discovering the cases where the build fails at the root.log stage. In the cases where the installation fails because some package FTI, all the rebuilds that use that package are going to fail. So we could delay those rebuilds until that package has been successfully rebuilt. But even that case can be more complicated: maybe the package FTI because of a problem in some other package, and suddenly the FTI goes away without the package being rebuilt? Actually, if we do the rebuilds in alphabetically, it'll be a while before we try again, which is not a bad approach. So overall, the current approach is better than people appreciate. Maybe we could improve some corner cases, but there are no magic improvements to be made. Zbyszek -- _______________________________________________ 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
