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

[Alexis Ballier]

On Tue, 21 Mar 2017 09:43:37 +0100
Kristian Fiskerstrand <k_f@g.o> 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.

Technically there's 0 difference: you can very well name your elibs
"${CAT}-${PN}-${VERSION}.eclass" and use the eclass mechanism.


> 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)

I'll skip the eblit vs nothing comparison.

(up to discussion ofc)

Pros for eblits vs the above eclasses:
- Let eclass/, which is a toplevel directory, be a place for code
  useful to several packages, not a random dump of whatever people want
  to share between ebuilds of the same package (yes, I'm looking at
  you toolchain or apache2.eclass :) ).
- Eblits being in package directory, repoman checks can be extended to
  look there.
- Have a guarantee that eblits are specific to a single package and
  cannot "leak" to others by mistake: It greatly simplifies changing
  and updating them.
- Eblits can be versionned, just the same as ebuilds or eclasses, but
  old versions have a life expectancy more of the order of an ebuild
  than that of an eclass. "Newborn" eblits would be expected to be
  much more frequent than eclasses but less frequent than ebuilds.
- Eblits being per-package they'd obey to package rules, not eclass
  rules wrt additions, removals, api-preservation, etc.

Cons:
- Need a new, somewhat redundant, mechanism.
- Can be done without new EAPI but is then restricted to src_* phases.
- Very few consumers at the moment (though, considering the current
  crusade that's not really a relevant metric to me).