Re: [gentoo-dev] Re: [PATCH] sys-devel/autoconf: Convert from eblits into an eclass, #586424

[Joshua Kinard <kumba@gentoo.org>]

On 03/21/2017 04:43, Kristian Fiskerstrand wrote:
> On 03/21/2017 09:28 AM, Joshua Kinard wrote:
>> In general, the concept of code-sharing common blocks of logic between multiple
>> ebuilds in a specific package directory that is not a top-level eclass is not
>> entirely without merit.  But the only way this idea can be realized in a
>> suitable manner and be used by far more consumers than today's eblits are, is
>> to either find and finish the old elibs GLEP or start one over from scratch,
>> submit whatever needs submitting via patches to at least PMS and Portage, work
>> through whatever processes are required for approval, and then deploy it in the
>> next EAPI.
>>
>> If anyone is game for working something up or discussing further, let me know.
> 
> I personally fail to see good reasons to have a separate approach for
> this instead of putting it in the eclass framework. However this might
> simply mean I'm missing something in the discussion.
> 
> Before restarting such a GLEP process; maybe a simple pros and cons list
> of comparison of the future eblit use and existing eclass structure
> could be helpful? (along with more description of the differences)

Well, maybe it's a sign of my age and tenure, but I always thought one should
be conservative in the definition of new eclasses.  I may be wrong, but back in
the old days, to define a new toplevel eclass, I believe one had to demonstrate
that a number of different packages all had common ebuild logic that could all
merged into a single eclass.  Kinda like what we do now with new global USE
flags.  So throwing package-specific eclasses into the toplevel eclass
directory seems to run against this.  Additionally, repoman does not validate
the logic in eclasses currently (a long-time issue), which can lead to code rot
of such package-specific common code.

That said, I'm not wedded to the current implementation of eblits as they
exist, and IMHO, I do agree in principle with QA that any such feature like
that needs to be defined in PMS and employed by the package manager in some
capacity.  It is certainly doable right now with an eclass (I even have an
example eblit.eclass that demos this), but it would be better to leverage
existing loading and sourcing logic within the package managers for such a
capability, which means changing them and updating PMS, which effectively means
a new EAPI.

How we go about implementing this idea, or whether we even bother to do so, is
what needs to be discussed.  I certainly have some ideas, but I've largely
isolated myself to the MIPS world the last few years and my ideas might not be
the best when applied elsewhere in the tree.  As such, starting a GLEP is
probably the best approach, elsewise, this idea will just die on the mailing
lists yet again.  I'm just not sure when I'll have some free time to educate
myself on GLEPs and throw a draft together.  I've lately been trying to chase a
really obscure kernel bug down on one of my SGI systems in addition to other
life responsibilities, so a GLEP is somewhat low priority right now.

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic