[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fedora-devel-list
Subject:    Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update
From:       Igor Gnatenko <ignatenkobrain () fedoraproject ! org>
Date:       2019-07-24 11:36:15
Message-ID: CAFMg4WDKYosuzr+QPk572n6QbFoXiXR3U085GTqHn1nS6r-fHw () mail ! gmail ! com
[Download RAW message or body]

On Wed, Jul 24, 2019 at 1:07 PM Florian Weimer <fweimer@redhat.com> wrote:
>
> * Stephen Gallagher:
>
> > With my FESCo hat on, I can't support this action as currently stated.
> > 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
> > x86_64.
>
> 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.

This depends on RPM and libsolv "archpolicy". So yes, as long as
dependencies do not change, it is fine. We need to keep %{?_isa} to
provide x86_64.

> 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?

Yes, that was my proposal.

> 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
> _______________________________________________
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-leave@lists.fedoraproject.org
> 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@lists.fedoraproject.org
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@lists.fedoraproject.org
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@lists.fedoraproject.org

[prev in list] [next in list] [prev in thread] [next in thread]