Re: Fedora 32 Self-Contained Change proposal: Additional buildroot to test x86-64 micro-architecture update

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

 



On Thu, Jan 16, 2020 at 7:46 AM Neal Gompa <ngompa13@xxxxxxxxx> wrote:
>
> On Thu, Jan 16, 2020 at 8:43 AM Justin Forbes <jmforbes@xxxxxxxxxxx> wrote:
> >
> > On Thu, Jan 16, 2020 at 7:11 AM Neal Gompa <ngompa13@xxxxxxxxx> wrote:
> > >
> > > On Thu, Jan 16, 2020 at 8:01 AM Aleksandra Fedorova <alpha@xxxxxxxxxxxx> wrote:
> > > >
> > > > Hi, Chris,
> > > >
> > > > On Fri, Jan 10, 2020 at 4:29 PM Chris Adams <linux@xxxxxxxxxxx> wrote:
> > > > >
> > > > > Once upon a time, Aleksandra Fedorova <alpha@xxxxxxxxxxxx> said:
> > > > > > Similarly to what Josh said, we want to setup an environment for experiments.
> > > > > > It doesn't mean that things we experiment on are going to be merged in
> > > > > > Fedora. And it definitely doesn't mean that whatever we did in the
> > > > > > experimental environment can bypass the approval process.
> > > > > >
> > > > > > It is not a backdoor for rejected change, it is a way to safely
> > > > > > iterate on the rejected change to see if we can come up with a version
> > > > > > of it, which won't be rejected.
> > > > >
> > > > > So... I guess my objections are all based on the proposal as written,
> > > > > which doesn't sound to me like what you are describing.  What the
> > > > > proposal says is all about rebuilding Fedora with the rejected baseline
> > > > > change, and showing that it is better to get the community to accept the
> > > > > original change.  It also uses the term "older machines" (which is still
> > > > > misleading).
> > > >
> > > > I have adjusted the description of the change in a way that I think
> > > > clarifies this part. Please check if it is better now.
> > > >
> > > > Also I've posted some context in a separate thread [1].
> > > >
> > > > I think the current change is important to Fedora also as a showcase
> > > > that we, as a project, care not only about the internal distribution
> > > > matters but in some large developments in the "outside world".
> > > > That we can also provide a venue for, for example, hardware vendors to
> > > > show their newest work.
> > > >
> > > > The rejection is a valuable feedback here, it highlights that it is
> > > > not enough to just push a new hardware spec to the market to get it
> > > > adopted. But we can also try to find a way how actually it _can_ be
> > > > done better.
> > > >
> > >
> > > I'll be honest: for me, not changing the architecture value that RPM
> > > uses for this is a hard blocker for me. The current proposal for
> > > distinguishing packages is unnecessarily confusing and makes it
> > > difficult to segment in Koji. If I hand-wave away all the other issues
> > > with this proposal (including that I'm still uncertain of the true
> > > purpose of this Change), the fact that RPMs with a new baseline will
> > > pretend to be the same architecture as another in a manner that we
> > > cannot codify a control for compatibility in RPM itself is simply
> > > unacceptable.
> > >
> > > This proposal simply illustrates one of the biggest problems with the
> > > way architectures are currently handled: we don't really leverage
> > > sub-arches or anything of the sort, so it's quite difficult to discern
> > > this minutiae otherwise. Without changing the architecture value, we
> > > also cannot implement a meaningful way for RPM to block the
> > > installation of these packages on computers that don't meet the CPU
> > > requirements.
> > >
> > > If we really want to do this, my ask is that you get RPM upstream to
> > > give you a new architecture label and have the hardware detection in
> > > place to keep people from breaking their systems with these packages.
> > >
> >
> > So, I had actually come up with an idea for this last summer when the
> > changes were originally proposed, but it is a non-trivial amount of
> > work. I think having this separate experimental build root is a good
> > way to see if it is even worth putting in that work to come up with a
> > more manageable solution for future work.  My idea from before is
> > below.
> >
> > rpm has package "flavors" at build time. This is a new field, but you
> > can build variants with different flavors. The flavor gets populated
> > into the repo metadata. DNF has a list of flavors which the system
> > supports. For right now, that might be AVX2, perhaps other things as
> > well. DNF treats flavors as a "preference" not a hard rule, so when
> > looking for updates, it will prefer the flavors that the system
> > supports, but if a package is not available in that flavor, it
> > defaults to unflavored or just the arch.  Anaconda sets the flavor
> > based on detection at install time, or it can be edited on the system
> > (even better if we could autodetect a lot of it at either DNF runtime,
> > or with a script). While it seems a lot of work, we do have a bit of
> > time, and putting such a thing into place will have long term
> > benefits.  It is extendable to many different things.  The end result
> > is a single repository (x86_64) with multiple flavors of the same
> > package (kernel-5.2.2-1.x86_64.rpm, kernel-5.2.2-1.x86_64.avx2.rpm,
> > etc).  The other advantage to this scenario is you can add or take
> > away multiple flavors of a package at any given time. Since it is just
> > a preference, if a flavor goes away, it falls back to arch.  If a
> > flavor is added, which a system lists as "preferred", on the next
> > update, that flavor is chosen, even if the current package is
> > unflavored.
>
> This is new to me, any documentation on this somewhere? I've not heard
> of this capability before...
>
As I said, it was a proposal, not something that currently exists. But
by doing a side repo  as an experiment, it might give the data to see
if such an idea is even worth putting the work into making something
like this possible.

Justin
_______________________________________________
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