On Fri, 2021-01-08 at 19:10 +0100, Thomas Deutschmann wrote: > On 2021-01-08 18:06, Mike Gilbert wrote: > > I disagree with your premise: I argue that the eclass is not "broken", > > and the code works as designed. You just don't like aspects of its > > design. > > Several people, not just me... *users*, other devs like robbat2 and > antarus, all with experience in maintaining multiple systems not just as > a hobby, have expressed that the current design has a flaw.
They did. What you're neglecting to repeat is that they've also indicated that your proposed design is flawed as well. You're conflating 'design A is flawed' into 'design B is better', while they really said 'both design A and B are flawed'. > I got feedback from other devs representing a large group in Gentoo and > they all agree on the problem. They haven't spoken up yet because they > don't care because the way how they use Gentoo is stateless. > > So why the hell is it acceptable for a small group (you and mgorny, > Michael told me already last year that he will be fine with an opt-in > change and I assume his opinion hasn't changed) to cause problems for > another group just because you don't want to acknowledge the problem? So what's you're basically saying is that there are people who like behavior A, people who like behavior B and people who don't care. Somehow you manage -- without any hard evidence -- to claim that people who dislike the current behavior are more numerous than the people who like the current behavior, and also implicitly count people who don't care towards them (why?). Even if you managed to prove that (how?), is this really a popularity contest? The current behavior has been the default for 1.5 years. There are ebuilds that literally depend on it. If you are going to change that, then you need to prove that 1) your proposed solution is much better for the vast majority of Gentoo users (again, how?), and 2) that the benefit from the change in behavior outweighs its costs. And given that you've pretty much admitted that the majority probably 'does not care', then 2) is not met. > Even soap, not sure if he has spoken for himself or as QA lead, has > acknowledged in this thread that we need a mechanism to disable this > behavior. > > Is it really not possible to solve this technical problem? Do we have to > escalate and need a vote or something to replace entire GLEP 81 with > something new just because a group believes there is no flaw and > everyone else having problems are doing things wrong so this group is > rejecting any attempts to address the problem? Again, I don't understand why you continue escalating this. I have already indicated that I'm fine with adding an option to disable this, given that 1) the current behavior remains the default, and 2) people are given big fat warning that they are now responsible for updating their users (and ideally 3) the eclass tells user how to update the user). I've just asked for the option to override values via make.conf goes first since that is the preferred solution that doesn't destroy the foundations of GLEP 81. floppym has indicated an interest in this, so I've presumed he's going to submit an updated patch to the ml. -- Best regards, Michał Górny
