For those who did not follow gentoo-project@, the previous posts include:
https://marc.info/?l=gentoo-project&m=168918875000738&w=2 https://marc.info/?l=gentoo-project&m=168881103930591&w=2 On 12/07/2023 21.28, Alec Warner wrote:
On Wed, Jul 12, 2023 at 12:07 PM Florian Schmaus <f...@gentoo.org> wrote:Apologies for not replying to everyone individually. I thank my fellow council candidates who took the time to reply to this sensitive and obviously controversial matter. I understand that not everyone feels comfortable taking a stance in this discussion. I asked the other council candidates about their opinion on EGO_SUM. Unfortunately, some replies included only a rather shallow answer. A few focused on criticism of my actions and how I approach the issue. Which is obviously fine. I read it all and have empathy for everyone who feels aggravated. You may or may not share the complaints. But let us focus on the actual matter for a moment. Even the voices raised for a restricted reintroduction of EGO_SUM just mention an abstract limit [1]. A concrete limit is not mentioned, although I asked for it and provided my idea including specific limits. Not knowing the concrete figures others have in mind makes it difficult to find a compromise. For example, a fellow council candidate postulated that it would be quicker for me to implement a limit-check in pkgcheck than discuss EGO_SUM. I wish that were the case. Unfortunately it is potentially not trivial to implement if we want such a check to be robust. But even worse, a specific limit must be known before implementing such a check. And we currently have none.I think my concern here is that I don't expect the Council to really 'vote on a specific limit.' The limit is an implementation detail, it can change, it shouldn't require a council vote to change. So my advice is "pick something reasonable that you think holds up to scrutiny, and implement with that" and "expect the limit to change, either because of the scrutiny, or because it might change in the future" and implement your check accordingly (so e.g. the limit is easily changeable.)
Please find below why this may not be enough.
But the real crux of an EGO_SUM reintroduction with a limit is the following. Either the limit is too restrictive, and most packages are affected by it and can not use EGO_SUM, which ultimately only corresponds to the current state. Or the limit only affects a fraction of the packages, so you should not bother having a limit.Again the idea is there is already a limit ( the aforementioned environment limit ) and one of the goals is to have a QA check that says your ebuild is approaching that limit so you can do something productive about it, as well as to avoid ebuilds that are not installable. So just implement that. If you need a number, I think "90% of the env limit" is defensible (but again, any reasonable number will do fine.)
EGO_SUM affects two dimensions that could be limited/restricted: A) the process environment, which may run into the Linux kernel environment limit on exec(3) B) the size of the package directory, where EGO_SUM affects the size of ebuilds and the ManifestI would be happy to put in any effort required to implement A) in pkgcheck, as I did for portage, if this check is the only thing that keeps us from reintroducing EGO_SUM.
Unfortunately, some argue that we need to limit B). Much of the effort I put into researching the EGO_SUM situation was analyzing how EGO_SUM's impact on package-directory size affects Gentoo. The result of the analysis strongly indicates that rather large package-directories can be sustained by ::gentoo in the foreseeable future. Especially since we are only talking about ~250 EGO_SUM packages currently, and a significant fraction of those packages will not have enormous package directories. And I also suggested that the policy is reconsidered at least every two years or once the number of EGO_SUM packages has doubled (whatever comes first).
My investigation of the history of EGO_SUM's deprecation has not surfaced any technical issue which justified EGO_SUM's deprecation with regard to B). It appears that technical issues do not drive the desire to limit B), but by esthetic preferences, which are highly subjective.
A), however, is a different beast. There is undeniably a kernel-enforced limit that we could hit due to an extremely large EGO_SUM (among other things). However, the only bug report I know that runs into this kernel limit was with texlive (bug #719202). The low number of recorded bugs caused by the environment limit matches with the fact that even the ebuild with the most EGO_SUM entries that I ever analyzed, app-containers/cri-o-1.23.1 (2022-02-16) with 2052 EGO_SUM entries, does *not* run into the environment limit.
The deprecation of EGO_SUM was and is unnecessary, a security issue, and was almost wholly *not* driven by technical problems. EGO_SUM should be re-instated. I know that some think likewise. I also know that others disagree. The latter group includes some prominent and visible Gentoo developers. People to whom I am thankful for their work on Gentoo and to whom Gentoo owes a lot. However, it is unclear what the majority of Gentoo developers thinks. I could very well be that the consensus amongst Gentoo developers agrees with some of my fellow council candidates and would like to keep the current state. It would be great if we find that out. If we had a mechanism to perform a non-binding opinion poll amongst Gentoo developers, and if that poll turns out that the consensus is to keep EGO_SUM deprecated, then I could save myself a lot of time and effort.I'm confused why you are asking about the 'consensus amongst developers' and then ask the council to vote.
If I knew that the majority of Gentoo developer's is fine with the deprecation of EGO_SUM, then I would not put in effort in re-instating EGO_SUM.
However, as of now, my conscience demands that I try to improve this situation for the sake of our users. In a previous mail, I wrote that I seek closure by asking the council to vote on that matter. And I will, of course, accept any outcome of that vote.My impression of the situation is that: - Currently if asked, the council would likely vote no. - They have requested you implement a QA check with a limit, and if you did that, many swing voters would vote yes. My guidance from above is "implement the check with some reasonable limit" to unblock your swing voters, so they vote yes... We don't need everyone to vote on what the limit is ..it's just wasting time IMHO.
It is not about everyone voting on that matter.It is about asking everyone of their opinion on that matter, in a non-binding opinion poll where multiple options can be ranked [1]. Chances are that this would surface the consensus amongst Gentoo developers, and ideally, the Council would take the result of the poll into consideration when voting on that matter.
- Flow1: I think that it is probably trivial to re-purpose our current voting infrastructure to perform opinion poll using the condorcet method.
OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
