Stephen Gallagher (sgallagh@xxxxxxxxxx) 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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
