Artur Frenszek-Iwicki venit, vidit, dixit 2025-01-18 11:23:22: > While I agree with the general idea of building things in order > of requirements, one problem that I can see with this approach is: > what happens when a higher-tier package fails to build? > > With the current, alphabetical approach, every package gets rebuilt > and then individual maintainers have to fix the failures. This may > be tedious from the perspective of an individual, but systemically, > it ensures that every package gets rebuilt. [snip] Building things in dependency order: The dependencies form a directed graph which is mostly acyclic. I am pretty sure it has *way more* "generations" than the 2 or 3 suggested tiers. So, the problem of what to do in case of a failure (complete that level first or ignore) can occur at way more levels than just 1 or 2. So, unless we don't want to ignore it or drag the mass rebuild out for ages, the only practical approach would be a tree walk. ... and then the "mostly": we do have cycles, some of which can only be resolved by bootstrapping. Building things in alphabetical order: This is dead simple but has more problems than apparent. Say, package A depends on package B. A is built first against the pre-rebuild version of B. B is rebuilt after. In most cases, the latter will work but produces an A in the side-tag which is not rebuilt against the B in the side-tag. Again, in most cases this may not be a problem. But with something like the rushes gcc15 side-tag merge right before the rebuild, it means that many packages were not rebuilt against gcc15. Say, in the example above, B is one such package. Then A is rebuilt during the mass rebuild against gcc15 and against a B which has been built with gcc14. B FTBFS during the mass-rebuild, gets fixed finally and built against gcc15 in the mass rebuild. After mergen, we have a gcc15 A and B, but A has been rebuilt against the gcc14-B. This may or may not FTI, may or may not work. So really, both approaches are difficult. Alphabetical order is practical but very brittle, in particular if rawhide is not "in good shape" or very volatile before the mass rebuild. We should stabilize rather than rush things in before. Michael -- _______________________________________________ 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
