On Fri, Mar 11, 2022 at 5:51 PM Yaakov Selkowitz <yselkowi(a)redhat.com> wrote:
(snip)
I don't see the opt-out as being "simple" at all, as
IIUC all it would take is
one maintainer not paying close enough attention to reverse dependencies to
break the i686 buildroot. Not to mention that it ends up polluting the vast
majority of packages with a spec file change that isn't technically accurate
(since the package *could* be built for i686, we've just choosing not to, and
the proper place to express that is in the build tag's arches).
Since the number of packages actually needed for i686 -- wine and its deps,
plus deps for those RPM Fusion i686 library packages, it seems -- should be a
small minority of the entire distribution, it should be those where the
changes are made. Doesn't it make more sense to special-case the exception
rather than the rule, as it requires fewer changes? (FWIW IMO package.cfg
files should be better than hardcoding a list in fedpkg, as the former doesn't
require the lag time involved in pushing an update when the list changes.)
It also avoids this becoming a piecemeal change, which will likely drag on for
years if left to individual maintainers.
Please stop moving goalposts. The goal of my proposal was never to
drop support for i686 from *all* possible packages.
It's about making it easy to drop unnecessary support for i686 from
packages *where it matters to the maintainer*.
And for this reason, I think a simple *opt-out* mechanism is the best solution.
If you want to talk about making it the norm to drop support for i686
unless the maintainer does *opt-in* to i686 for multilib, then that
can be a follow-up Change that can build on top of this one. But
please don't conflate the two things, as they are very different.
Fabio