On Wed, Nov 17, 2021 at 11:53 AM Zbigniew Jędrzejewski-Szmek
<zbyszek@xxxxxxxxx> wrote:
>
> On Tue, Nov 16, 2021 at 03:05:37PM -0500, Robbie Harwood wrote:
(small snip)
> > Is it really not? This seems the easiest way to go about it, honestly -
> > just have it be permitted for maintainers to opt their stuff out of
> > building on x86 and let the problem take care of itself recursively.
>
> Yeah, I think I'd go this way too. Instead of trying to maintain this
> centrally in koji, do it at package level, using proven-packager privileges
> to smooth the initial process.
>
> I.e. something like: OK, we don't want to build libreoffice for i686.
> libreoffice is annotated with "ExcludeArch: %{ix86}", and *at the same time*
> any packages which (transitively) BR:libreoffice, are also annotated.
> (They don't even need to be rebuild.)
> And then repeat for another "big" package.
>
> I think this way to go is OK because we mostly care about some of the
> "big" packages that take a long time to build. Most low-level packages
> build just fine on i686 so we don't care if they are built unnecessarily.
>
> And obviously the advantage is that this can be done now, and doesn't
> require any new infra or maintenance. The only trick would be how to
> figure out the transitive BR tree, but apparently there are some scripts
> that people have.
I really *don't* think a manual, individual opt-out like this is a good idea.
Imagine the scenario where a package maintaner unilaterally adds
"ExcludeArch: %{ix68}" to one of their packages. This might be an
honest mistake, for example, because the repoquery was not done
correctly, or because they thought that nothing depends on that
package. Then, this results in cascading build failures of all
dependent packages, because a broken build on any arch fails the whole
build, requiring cascading changes to all packages in the dependency
tree, more work for all manitainers that are involved.
Because I think we should respect package maintainers' time, I don't
think I should put the burden of figuring this out and fixing
breakages on them, which is why I suggested a centralized approach
that will not put more work on *every single package maintainer*.
Fabio
_______________________________________________
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 on the list, report it: https://pagure.io/fedora-infrastructure
