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
