On 01/05/2017 10:35 PM, Bill Nottingham wrote: > Stephen Gallagher (sgall...@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?).
Part of the situation is that we're building a new build process to deal with modules. In that situation, we're trying to avoid some of the complexity that has grown up over the years with our traditional build system. What my goal is here is to figure out a strategy that can work for both efforts so we don't have two completely different workarounds for the same problem.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
