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