* Stephen Gallagher:
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.
Thanks,
Florian
* Stephen Gallagher:
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.
Thanks,
Florian
Something like this sounds like a good idea to me.
Would it be possible to work this out into a standardized way to provide support for
multiple ISA levels, e.g. avx, avx2, avx512 or whatever might come up in the future? That
way fedora could stay up to date with recent cpu developments without regularly having
discussions like this one.
Instead of providing multiple x86_64 spins, where each user has to figure out on their own
which one to use, it might be better to only deliver installers with the baseline and let
them figure out the right optimized packages at install time.