On Thu, Jan 16, 2020 at 8:43 AM Justin Forbes <jmforbes(a)linuxtx.org> wrote:
On Thu, Jan 16, 2020 at 7:11 AM Neal Gompa <ngompa13(a)gmail.com> wrote:
> On Thu, Jan 16, 2020 at 8:01 AM Aleksandra Fedorova <alpha(a)bookwar.info>
> > Hi, Chris,
> > On Fri, Jan 10, 2020 at 4:29 PM Chris Adams <linux(a)cmadams.net> wrote:
> > >
> > > Once upon a time, Aleksandra Fedorova <alpha(a)bookwar.info> said:
> > > > Similarly to what Josh said, we want to setup an environment for
> > > > It doesn't mean that things we experiment on are going to be
> > > > Fedora. And it definitely doesn't mean that whatever we did in
> > > > 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
> > > > 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
> > > 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 .
> > 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
> 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
> 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
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
This is new to me, any documentation on this somewhere? I've not heard
of this capability before...
真実はいつも一つ！/ Always, there's only one truth!