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