https://bugzilla.redhat.com/show_bug.cgi?id=1686307 --- Comment #26 from Ben Beasley <code@xxxxxxxxxxxxxxxxxx> --- (In reply to Sandro from comment #25) > (In reply to Adam Williamson from comment #24) > > Hmm, okay, so it seems like it was Ben Beasley's idea, and the idea was to > > force dask to build on all arches so the tests would run on all arches and > > catch any problems, but the installable subpackages would all be noarch. > > However, it never worked out this way, because he didn't think about the > > %pyproject_extras_subpkg subpackages. > > I think the general idea with that approach was/is that it builds on all > arches indeed. Because with `BuildArch: noarch` you don't know which builder > will be chosen and it is annoying seeing you scratch build succeed and the > real build fail because it is on a different arch. But I let Ben speak for > himself (cc'ed). Yes, that’s the motivation. In neuro-sig, we do this in a lot of numerical and file-format library packages because arch-dependent test failures are so very common. Often we add it to previously-noarch packages when we find and fix an arch-dependent issue. To be honest, I *knew* that the extras metapackages would be arched, but I didn’t feel that it *mattered*, because metapackages don’t ship any files so the wasted space on mirrors by having a cooy for each architecture is negligible. For python-distrubuted, there’s some risk of arch-dependent issues in the shuffling or serialization/deserialization code, but I also think it would be justifiable to start out with it noarch and then revisit that it if it develops one or more arch-dependent packages in practice. More discussion in bug 2293727. -- You are receiving this mail because: You are always notified about changes to this product and component You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=1686307 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%201686307%23c26 -- _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-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/package-review@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
