Stephen Gallagher (sgallagh(a)redhat.com) said:
The main reason for this is trying to simplify the module-building
process. We
really don't want to attempt to build both arches within the same buildroot for
most of the reasons we've established in this extended conversation. My first
proposal was one possible approach for this, but this second idea would solve
the same problem, possibly with less jarring impact.
While I fully understand how our current multilib system is a mess for the
build and release process (being in certain respects responsible), I'm leery
of using that to make drastic changes.
The whole point of building an OS/module/etc for users is to keep the
complexity on the build side and out of the users hands - they don't care
whether half the packages switched from autoconf to meson, whether twenty
things are now written in Rust, or whether the entire python stack jumped
minor (or major!) versions. They just want the system to upgrade and the
software they use to keep working.
If the multilib change only brings benefits to our build process and breaks
user cases without offering significant benefits to them, I can't see the
justification for it until we can offer end-user benefits (... ostree?).
Bill