On Fri, Sep 2, 2022 at 1:43 PM Richard Shaw <hobbes1...@gmail.com> wrote: > >> If looking at a single package in isolation it may look wasteful, but from >> the POV of the distro as a whole packages with potential mingw sub-RPMs >> are a small subset of what goes through koji every day. > > > Perhaps, but the engineer in me finds this very distasteful :) > > It would probably be too much work but it would be useful to have a > pseudo-arch "mingw" which would just build on the first available "noarch" > builder.
Building noarch subpackages on multiple architectures actually provides some benefits, even if some - or all - of the output is thrown away: - architecture-specific bugs that result in generation of different "noarch" subpackages get caught (which they wouldn't be if the "noarch" subpackage were only ever built once) - you can run tests for the functionality that's provided by the "noarch" subpackages on different architectures - etc. For example, all Rust library packages build only "noarch" subpackages, but the packages themselves are built on *all* architectures, because we want to know whether the shipped code actually *compiles* and tests *succeed* on all supported architectures. If we didn't do that, catching architecture-specific bugs would be much harder, and would only result in random problems, or build failures in leaf *application* packages instead of in the package that actually has the problem. I might remember wrong, but doing the same for Python packages was thought about a few years ago to catch architecture-specific issues more consistently (and not only iff the noarch python package happens to randomly be built on the failing architecture every now and then). Fabio _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
