public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Florian Schmaus <flow@gentoo.org>
To: Sam James <sam@gentoo.org>, council@gentoo.org
Cc: gentoo-dev <gentoo-dev@lists.gentoo.org>,
	William Hubbs <williamh@gentoo.org>
Subject: [gentoo-dev] Re: EGO_SUM
Date: Wed, 26 Apr 2023 17:31:00 +0200	[thread overview]
Message-ID: <c95c85b1-a8c7-7010-96c3-79773f445126@gentoo.org> (raw)
In-Reply-To: <87o7nd58by.fsf@gentoo.org>

Hi Sam,

thanks for your feedback. I am glad for everyone who engages in this 
discussion and shares their views and new information.

On 24/04/2023 22.28, Sam James wrote:
> Florian Schmaus <flow@gentoo.org> writes:
> 
> [CCing williamh@ as go-module.eclass & dev-lang/go maintainer.]
> 
>> I like to ask the Gentoo council to vote on whether EGO_SUM should be
>> reinstated ("un-deprecated") or not > In the various previous discussions, the need
> for _some_ limit to be implemented (derived from EGO_SUM) was clear from
> the QA team and others.

Asking to impose an artificial limit is based on the same unfounded 
belief under which EGO_SUM was deprecated in the first place. I am 
worried that if we follow this, then a potential next step is to argue 
about adding packages to ::gentoo.


> Voting on the matter now would be reopening the issue which led EGO_SUM
> to be deprecated in the first place, with only a partial mitigation
> (the Portage warning).

I am sorry, but I do not follow. I think this is partly because it is 
not clear "what" (else) to mitigate.

The discussion would be more productive if someone who is supporting the 
EGO_SUM deprecation could rationally summarize the main arguments why we 
deprecated EGO_SUM.


> Any such limit should be supported by pkgcheck, allow using EGO_SUM
> for most packages, but exclude the pathological cases which we're
> unlikely to want in ::gentoo.
> 
> (Limit-per-ebuild rather than per-package is one option of many,
> too.)

As you probably noticed, I am not aware why we should impose such a 
limit. Especially a per-package limit confines the ability to provide 
the user with multiple versions of a package, which sometimes comes in 
handy [1].


>> Most voices on the related mailing-list threads expressed support for
>> reinstating EGO_SUM. At least, that is my impression. While the
>> arguments used to deprecate EGO_SUM were mostly of esthetic nature.
>>
>> I want to state what should be common sense. Namely, asking for a
>> democratic vote is not a personal attack against any involved
>> person.
>> [...]
> 
> I agree this is an important issue that affects the practicality
> of using Gentoo for some, and for contributing to Gentoo to others.

Same data point: Just in the last few days, multiple users reported in 
#-guru issues they wouldn't have had if EGO_SUM was not deprecated.

- Flow

1: From my experience, this is also something Gentoo is praised for.


  parent reply	other threads:[~2023-04-26 15:31 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-17  7:37 [gentoo-dev] EGO_SUM Florian Schmaus
2023-04-17  9:28 ` [gentoo-dev] EGO_SUM Anna (cybertailor) Vyalkova
2023-04-27 18:00   ` William Hubbs
2023-04-27 18:18     ` David Seifert
2023-04-24 16:11 ` Florian Schmaus
2023-04-24 20:28   ` Sam James
2023-04-24 22:52     ` Alexey Zapparov
2023-04-26 15:31     ` Florian Schmaus [this message]
2023-04-26 16:12       ` Matt Turner
2023-04-26 19:31         ` Andrew Ammerlaan
2023-04-26 19:38           ` Chris Pritchard
2023-04-26 20:47           ` Matt Turner
2023-04-27  7:58         ` Florian Schmaus
2023-04-27  9:24           ` Ulrich Mueller
2023-04-28  6:59             ` Florian Schmaus
2023-04-27 12:54           ` Michał Górny
2023-04-27 23:12             ` Pascal Jäger
2023-04-28  0:38               ` Sam James
2023-04-28  4:27                 ` Michał Górny
2023-04-28  5:31                   ` Sam James
2023-04-28  6:59             ` Florian Schmaus
2023-04-28 14:34               ` Michał Górny
2023-05-02 19:32                 ` Florian Schmaus
2023-05-02 19:38                   ` Sam James
2023-04-29 22:34               ` Robin H. Johnson
2023-04-27 21:16           ` Sam James
2023-05-02 19:32             ` Florian Schmaus
2023-05-02 19:45               ` Sam James
2023-05-08  7:53                 ` Florian Schmaus
2023-05-08 12:03                   ` Michał Górny
2023-05-22  7:14                     ` Florian Schmaus
2023-05-02 20:04               ` Matt Turner
2023-05-08  7:53                 ` Florian Schmaus
2023-04-26 20:51       ` Sam James
2023-05-30 15:52   ` Florian Schmaus
2023-05-30 16:30     ` Anna (cybertailor) Vyalkova
2023-05-31  5:02       ` Oskari Pirhonen
2023-05-30 16:35     ` Arthur Zamarin
2023-05-31  6:20       ` Andrew Ammerlaan
2023-05-31  8:40         ` Ryan Qian
2023-05-31  9:06         ` Arsen Arsenović
2023-05-31  6:30       ` pascal.jaeger leimstift.de
2023-06-01  4:00         ` William Hubbs
2023-06-02  8:17       ` Florian Schmaus
2023-06-02  8:31         ` Michał Górny
2023-06-09 10:07           ` Florian Schmaus
2023-06-01 19:55 ` [gentoo-dev] EGO_SUM William Hubbs
2023-06-02  7:13   ` Joonas Niilola
2023-06-02 18:06     ` William Hubbs
2023-06-02 18:42       ` Joonas Niilola
2023-06-09 10:07   ` Florian Schmaus

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c95c85b1-a8c7-7010-96c3-79773f445126@gentoo.org \
    --to=flow@gentoo.org \
    --cc=council@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    --cc=sam@gentoo.org \
    --cc=williamh@gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox