> * 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. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
