Zac Medico wrote: > Steven J Long wrote: >> Zac Medico wrote: >> >>> The specification is really the most important part, and you have to >>> give the -dev community an opportunity to participate in refining >>> the spec (via RFC email, GLEP, or whatnot). >>> >>> It seems like this idea will probably serve for bug 179800, which is >>> about allowing eclasses to register phase hooks: >>> >>> http://bugs.gentoo.org/show_bug.cgi?id=179800 >>> >> Hmm given that this relies on profile.bashrc, in specification terms one >> would have to ensure that http://bugs.gentoo.org/202631 (which was >> recently raised in #-council) were resolved. The sunrise people raised >> being able to tweak bashrc per-overlay in #-portage recently, and the >> phase hooks were also raised by javaJake wrt having directory-based >> hooks. > > For the overlay people, it seems like we need something that's a > little different from the existing profile support, since profile's > are user-selectable and it seems like you want something that's > global/mandatory at the repository level. For example, it could be > located at profiles/profile.bashrc, similar to > profiles.package.mask, which is global/mandatory rather than being > part of a specific user-selectable profile.
Yeah sounds right. Perhaps a per-category bashrc split (both for usual /etc/portage case and for overlays) might also be useful? (Overlay admin can always test PN should the need arise.) You mentioned in #-portage that per-phase execution is no longer used, wrt how overlays would only be executing bashrc at start. I take it we can still test $EBUILD_PHASE? (Sorry if I've misunderstood what you were saying.) -- #friendly-coders -- We're friendly but we're not /that/ friendly ;-)
