Re: [gentoo-dev] [PATCH] Split python implementations definition to separate eclass

[Michał Górny]

On Fri, 2020-03-27 at 13:22 -0700, Patrick McLean wrote:
> On Fri, 27 Mar 2020 06:53:13 +0100
> Michał Górny <mgorny@g.o> wrote:
>
> > On Thu, 2020-03-26 at 14:03 -0700, Patrick McLean wrote:
> > > This patch splits the definition of _PYTHON_ALL_IMPLS and
> > > _python_impl_supported to a separate eclass, this allows overlays
> > > to easily support a different set of python implementations than
> > > ::gentoo without having to fork the entire suite of eclasses.
> >
> > NAK.  This increases the maintenance effort (even if it means having to
> > open yet another file) for *zero* gain to Gentoo users.  Your policy is
> > entirely broken by design and I'm against supporting it officially.
> >
> > The existing number of eclasses is already causing confusion and added
> > maintenance effort, and it has strong justification in *a lot of shared
> > code*.
> >
> > To say it bluntly: if you want to do stupid things, do them yourselves
> > and don't expect others to help.  You get paid for that.  We just waste
> > our time.
> >
> It can hard to keep the size of network we have in sync with upstream,
> and we have quite a large number of internal repositories. The
> approaches we are using are trying to strike a balance between
> backwards compatibility and moving forward.
>
> We get paid to do our job, which sometimes coincides with doing
> upstream Gentoo work, and often doesn't. We have a policy to work
> upstream wherever possible, this often makes certain types of tasks
> take significantly more effort than if we just decided to fork
> everything and work an internal overlay. These small changes are an
> attempt to reduce the extra work that working upstream can create (we
> generally work to support the general use case of all Gentoo users, not
> just our limited use cases).
>
> Would Gentoo as a whole be better served if we just forked everything
> and stopped trying to contribute as much as possible upstream? Are some
> small changes to some shared code to help us worth the amount of
> contributions that we push back upstream.

I was thinking about it, and how about you ask Portage people to provide
an option to silently ignore dying ebuilds, rather than trying hard to
prevent the eclass from exploding when it's supposed to explode?  That
would certainly be better than turning the eclasses into a minefield,
and expecting me to consider 'will this cause some eclass fork to
explode?' every time I change some internal eclass bit.

-- 
Best regards,
Michał Górny