I've found some more info on this topic from the internet archive. - "[gentoo-dev] RFC: eblits.eclass" http://news.gmane.org/find-root.php?message_id=4BC0F659.7000506%40gentoo.org - https://github.com/transtone/zm-overlay/blob/master/eclass/eblits.eclass - https://wiki.gentoo.org/wiki/GLEP:33 - "RFC: Reviving GLEP33" http://thread.gmane.org/gmane.linux.gentoo.devel/67451
It seems that "eblits" is a relative to yet another concept called "elibs", which was proposed back in 2005 as GLEP33, but was never completed. As opposed to "elibs", "eblits" do not require any special EAPI or portage support and thus they're living and are tolerated to these days, as they do not interact with anything outside of their lawn. Based on the explanation given by Kent Frederic and Duncan, I'd sum it up as: "a way to share code between ebuilds of a certain package, living concurrently in different slots" Which can be abstracted as "isolated package-specific eclasses". Inter-ebuild code sharing really seems like a problem for maintainers of certain packages and eblits seem to provide a quick solution, so that answers the "why". This whole concept, however, raises the question (as suggested by Ciaran McCreesh and Duncan) if it's allowed to split ebuilds to several bash scripts and what have QA and dev-manual got to say in this regard? It's always better to have some official material rather than an oral tradition.
