Kevin Kofler (kevin.kofler(a)chello.at) said:
> While that would make things simpler and shorter, I doubt
it's really
> practical. Enough people use and want multilib that I don't think we can
> just unilaterally remove it. Moreover, the multilib portion of the compose
> isn't the primary time eater.
>
> I certianly don't want to go back to the whitelist case where every time
> someone needed a new multilib package we had to update a static whitelist
> in the update push tool. That's just silly.
Why can't we just tell them to add the 32-bit repo to their configuration?
Possibly even ship fedora-32bit and fedora-updates-32bit configs (disabled
by default)? With the exactarch=1 setting (the current default), this
shouldn't be a big problem. The only problem I see is that people would run
into file conflicts if they use exactarch=0 or yum install
someapplication.i686, but it's easy to close those as NOTABUG ("sorry,
multilib is not supported for this package, just use the 64-bit version").
If those reports become a big problem, isa-based Conflicts tags could be
added.
Off the top of my head, it would break the install DVD usage case and the wine
usage case. It would also make multilib_policy as a configuration option
meaningless, as you couldn't ever set it to anything other than 'best' and
expect it to work.
Bill