On 05/26/2016 18:28, rindeal wrote:
> I've noticed that ebuilds for at least dev-lang/perl and
> sys-libs/glibc are using some concept of "eblits", which seems like
> parts of ebuilds scattered across $FILESDIR with ebuilds containing
> some logic (involving eval) which includes and runs them.
> 
> I haven't found any documentation related to them so I'm asking here:
> 
> 1) what are they?
> 2) why are they used?

I'm the other user of eblits in sys-kernel/mips-sources.  There's a lot of
common code in that package that doesn't need to be duplicated between multiple
ebuilds, so years ago, I converted to using versioned eblits.  It's a touch
manual, in that I have to manually check that all consumers of a specific eblit
version are removed from the tree before I remove the deprecated version, but
it avoids the nasty problem of changing an eblit for a newer ebuild that breaks
an older ebuild.

I started on an "eblits.eclass" a few months ago, but sidetracked and didn't
get back to it.  Attached, if anyone wants to play with it.  It includes the
core eblit loading functions used in mips-sources, which might be more
updated/robust than the ones in glibc (last I checked the logic, but vapier can
clarify if true or not).  The last comment block is incomplete.  I sidetracked
in finishing item #2 when pondering how to define a global "check" variable in
the eclass itself to control when the eblit core functions were loaded and all
eblits parsed (see latest mips-sources ebuild, $MIPS_SOURCES_EBLITS_LOADED).

Also handles the case of when installing from binary packages and $FILESDIR
isn't available.  The eblit source for the pkg_* phases are packed onto the end
of the bzip2 tarball so they're available to Portage & friends.

The core eblit loading functions are the only duplicated code in the
mips-sources ebuilds, as well as glibc and other eblit users (perl?).  I don't
remember what the argument for or against eblits might have been back in the
day, but for ebuilds whose only real changes are datestamps and/or version
numbers, eblits are a nice way to encapsulate and share common code that is too
specific for a global eclass.  Centralizing the eblit code will allow
mips-sources and glibc ebuilds to shrink their overall filesize a little-bit
more (~1.5KB per mips-sources ebuild, so 3.4KB per ebuild instead of the
current 4.9KB).

And yes, for anyone wondering, I have new mips-sources ebuilds.  Just took a
month to partially rewrite the SGI Origin/IP27 kernel code and then hunt down a
hardware bug on my SGI Octane, so, been distracted...

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