Re: [gentoo-dev] stacking profile.bashrc?

[Zac Medico <zmedico@gentoo.org>]

Michael Haubenwallner wrote:
> On Wed, 2009-07-15 at 11:39 -0700, Zac Medico wrote:
>> Michael Haubenwallner wrote:
>  
>>> We do have post_src_install() hook in profiles/prefix/profile.bashrc ...
>>> In profiles/prefix/aix/profiles.bashrc, there is another
>>> post_src_install() hook ...
>>> The problem now is that the latter post_src_install() overrides the
>>> former, ...
> 
>> The pre/post phase hooks are not designed for this, they are only
>> intended for users to put in /etc/portage/bashrc. For what you are
>> trying to do, it seems like a registration interface would be more
>> appropriate (something like register_die_hook).
> 
> Should this registration api be provided by portage, or by
> base/profile.bashrc?
> Hmm, will have to be portage, because /etc/portage/bashrc would override
> base/profile.bashrc too. base/profile.bashrc just might jump in when not
> provided by installed portage yet.
> 
>>  Maybe the usage
>> could go something like this:
>>
>>   register_phase_hook install post my_post_src_install
> 
> For readability, I'd more like to have 'post' in front of 'install'.
> 
> Or eventually something like:
> 
>         register_phase_hook \
>           --before-src_install my_pre_src_install_1 my_pre_src_install_2 \
>           --after-src_install my_post_src_install_1 my_post_src_install_2 \
>           --before-<phase-function-name> <multiple hooks> 
> 
> Or with phase-names instead of phase-function-names:
> 
>         register_phase_hook \
>           --before-{setup,nofetch,unpack,prepare,configure,compile,...} <hooks> \
>           --after-{...,test,install,preinst,postinst,prerm,postrm} <hooks>
> 
> Suggesting "before&after" here as I'm always confused with
> pre_pkg_preinst, post_pkg_preinst, pre_pkg_postinst, post_pkg_postinst,
> pre_pkg_prerm, post_pkg_prerm, pre_pkg_postrm, post_pkg_prerm.
> 
> Anyway: besides implementation, what else does it need to get this done?

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

> 
> Thank you!
> 
> /haubi/


-- 
Thanks,
Zac