Gentoo Archives: gentoo-project

From: Rich Freeman <rich0@g.o>
To: gentoo-project <gentoo-project@l.g.o>
Subject: Re: [gentoo-project] [RFC] New project: GURU [Gentoo User Repository, Unreviewed]
Date: Mon, 04 Feb 2019 18:44:26
Message-Id: CAGfcS_=qsE7imRFDhkYv0fiYk6LurYzeNABG437+JnWp9TcSkg@mail.gmail.com
On Mon, Feb 4, 2019 at 1:32 PM Mike <mpagano@g.o> wrote:
> > I guess we should figure out the level of support users can expect to > receive from using this GURU repo. If someone forks a package I > maintain and then a user has issues I'm not sure how much 'official' > support they can expect. Certainly for complicated ebuilds, with > 'multiple right' ways of doing things, this could result in an > 'official' maintainer being at odds with the 'unoffical' one. Maybe we > have that now?
The original proposal raised that question. IMO we shouldn't allow namespace conflicts with the main repo. If the main repo has courier-imap then no package can use that name in GURU. Now, if somebody wants to maintain some fork of the package under a different name that is fine. And again I don't think we want to make it so that when a user installs one random GURU package that they automatically start pulling in every other package in that repo like they would a regular overlay. That will make it much harder for them to stay aware of potential issues. That problem can actually exist in the main repo, but in practice it doesn't come up much. If somebody wanted to stick a renamed chromium ebuild in the main repo that just defaults to duckduckgo or whatever that would technically be allowed by policy I believe. However, most devs are just going to use user patch support to do this sort of thing, especially considering the effort required to maintain a parallel package like that. There have been similar arguments over default USE flags (and associated patches) for stuff like openssh and bitcoin as well. At least within the main repo we have a pretty well-defined escalation path for QA/Council/etc. -- Rich