[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] What are eblits?
From:       Joshua Kinard <kumba () gentoo ! org>
Date:       2016-05-29 14:20:30
Message-ID: b48abfdc-0e56-1789-6244-5368878384c9 () gentoo ! org
[Download RAW message or body]

On 05/29/2016 04:25, Ulrich Mueller wrote:
> > > > > > On Sun, 29 May 2016, Rich Freeman wrote:
> 
> > What I would love to see is this be standardized. An eclass or a
> > GLEP seems like the logical approach.
> 
> I am strongly opposed against this. Ebuilds should not source
> executable code from random locations. This is also a huge QA
> violation, since PMS neither guarantees FILESDIR to be available in
> global scope (so especially, not during metadata generation), nor in
> any of the pkg_* phases (like pkg_setup, where mips-sources sources
> its eblits).

I believe this was addressed already back in 2010, for mips-sources at least.
Can't speak for the other eblit consumers.  See Bug #300370.

Eblits used to be loaded in global scope, which is what caused the $FILESDIR
issue, so the change was to move them into a function, then call that function
from pkg_setup.  This also makes sure the eblit code gets packed into the tbz2
so it's available when $FILESDIR isn't.

As for sourcing from random locations...point, because the standard path isn't
set in stone in an eclass or GLEP.  $FILESDIR/eblits is the path used by at
least glibc and mips-sources eblits.  I haven't looked at Perl or PHP's.
Totally open to addressing that in a sane manner.


> If there really is a need for such a feature, we should rather follow
> an approach like the per-package eclasses previously suggested by mabi
> and antarus [1], and support a pkg-inherit function in the next EAPI.
> (Though I wouldn't add a new function, but add an option to inherit,
> like "inherit -p".)

That seems like an attempt to revive the elibs idea, which is what eblits were
eventually supposed to morph into at some point.  I have no idea why elibs died
off.  Probably lack of interest or need back in 2005, when Gentoo was far, far
smaller in size and scope.

IMHO, to avoid that happening again, any such solution (regardless of name)
should probably look at implementing the bare minimum needed to replace all
existing consumers of eblits with the least amount of upheaval.  Then new
functionality can be added down the road.  Try to do everything at once, and
it'll just die off again.


> We could even think about per-category eclasses ("inherit -c"),
> although it is not obvious where one would store them.

Easy...under eclass/, in per-category sub-folders :)

(yay for more directory bureaucracy!)


> Ulrich
> 
> [1] https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/users/antarus/projects/gleps/glep-XX.txt?view=markup
>  


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


[prev in list] [next in list] [prev in thread] [next in thread]