* Stephen Gallagher:
With my FESCo hat on, I can't support this action as currently
I think I'd be more inclined to consider it if the Change was proposed
as a new architecture bring-up. Effectively, this would be a whole new
architecture that would just happen to be largely compatible with
Can we make this happen at the RPM level? So that third-party RPMs
install just fine even though the operating system is something else
(not x86_64 anymore)? I do not see many explicit dependencies on
anything “x86_64” in Fedora 30, so perhaps this is doable, assuming that
packages of the other architecture would continue to provide …(…)(64bit)
for soname dependencies.
Could we rebuild x86_64 Fedora with a different dist tag and different
compiler flags, and release that as a new spin? And retain the x86_64
for that architecture?
Regarding doing something like the old i686 packages when we had an i586
baseline (or the ppc64p7 work that was perhaps never upstreamed to
Fedora), I'm a bit worried about increasing the complexity of composes.
We already see upgrade issues doe to i686 packages come and go, and that
could potentially multiply them. The advantage is that packaging
changes themselves will be relatively minor, once we have agreemeent
which packages should do this.
ELF multilib DSOs inside RPMs result in code deduplication, affecting
container image size. Packaging changes are *not* minor for this
approach. It can be tricky to ensure full testing coverage if both DSOs
are installed. Currently, there is no dynamic loader support for
selecting an AVX2 baseline. Fixing this requires complete agreement
among all involved parties what the actual CPU requirements are
(currently, not even glibc and GCC agree what “haswell” means, the
closest we have to an AVX2 baseline). But similar fixes are required
for any baseline update.