Re: Fedora 32 System-Wide Change proposal: x86-64 micro-architecture update

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jul 24, 2019 at 1:07 PM Florian Weimer <fweimer@xxxxxxxxxx> 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@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
_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux