V Fri, Jun 24, 2022 at 03:29:59PM +0200, Vít Ondruch napsal(a): > > Dne 23. 06. 22 v 15:10 Miro Hrončok napsal(a): > > On 23. 06. 22 14:24, Aleksandra Fedorova wrote: > > > > 3) If every Fedora packager can rebuild anything without a > > > > commit, what do we > > > > do prevent accidental builds? > > > I think each rebuild should be treated as a new package, thus it would > > > require a new bodhi update, testing, and signing. Which means it will > > > be less likely to accidentally ship it. > > > > > > But as I mentioned in the post, right now we'd like to propose the > > > refactoring, and not a change of the development workflow. Thus I > > > would initially restrict the rebuild possibility to the admin group > > > which handles mass-rebuilds and other admin tasks. Then I would > > > gradually open it up case by case, each case through a separate > > > conversation. > > > > > > Saying that, probably the first case, which I would consider is: is > > > there a problem of an accidental rebuild of a merged code for Fedora > > > Rawhide? What would be the reasons for us to_not_ allow it? > > > > > > A specific example is this workflow: > > > > Imagine 200 packages need to be rebuilt with boost 1.99. > > > > 1) I build boost 1.99 in a side tag > > > > 2) I commit a bump to 200 packages > > > > 3) I submit a side tag build for 200 packages > > > > 4) I repeat (3) until it seems futile > > > > > > This solves the dependency order issues quite well. I also don't need to > > think about that much and scripting it is trivial. If the build > > previously succeeded, it won't do anything. If it failed, it will try > > again. > > > Isn't similar mechanism used by MBS? > Hammering builds until at least one of them get built? No. MBS use a build order written by packagers into the module YAML file. Adding build ID into RPM release? Yes. It's a necessity to be able to build the same sources in multiple, different build roots. > Anyway, this is quite common mechanism for mass rebuilds of all kinds. Just > hammer the builds. > There are optimized approaches: Koschei dry-installs a source package into a build root to decide whether build-dependencies are satisfied. perl-Fedora-Rebuild checks build-dependencies by computing a partial dependency graph. These tools prevent from spawing unnecessary builds. In general, you cannot predict which run-time dependencies a package will have, and you cannot precompute build order among all packages. You can only select a group of now buildable packages. Hence the number of checked packages before submitting them for building is O(n^2). But the number of submitted builds is kept in O(n) (not counting bootstraping builds). A donw side is taht these optimizations require perfectly specified dependencies. That's not true for whole Fedora. ELN people are probled closest to the reality. -- Petr
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to packaging-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/packaging@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
