Re: [gentoo-portage-dev] Portage phase hooks patch

[Zac Medico]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mike Kelly wrote:
> Hello,
>
> This is that patch I had mentioned earlier on #gentoo-portage. It works
> by sourcing every script found in
> /var/libexec/portage/hooks/{pre,post}_${EBUILD_PHASE} at the
> appropriate time.
>
> In my case, I feel this functionality would be very useful as it allows
> for me to integrate my GLEP 27 implementation into portage without
> portage needing to worry about my implementation specifics, which may
> well change in later versions. I am sure there are other practical ways
> in which these hooks could be used.
>
> Patch at: http://soc.gentoo.org/viewcvs.py/*checkout*/glep0027/patches/portage-hooks.patch
>
> See bug# 141215.
>

I like the idea.  My main concern is that, like /etc/portage/bashrc, this creates lots of potential for foreign code to interfere with the internal workings of the ebuild environment.  At a minimum, I think there should be something in the `emerge --info` output that indicates whether or not any phase hooks exist.

Traditionally, configurable files that affect portage behavior go mostly in /etc/portage.  I see that your intention is to make /var/libexec/portage/hooks/ a location for third-party packages to install hooks, so it makes sense to keep those separate from hooks that the user might install.  I know that portage-utils currently installs a post-sync hook in /etc/portage/postsync.d/q-reinitialize, so there is some inconsistency there.  We need to develop a consistent policy for appropriate locations of files like these.

Zac
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.4 (GNU/Linux)

iD8DBQFEwrpF/ejvha5XGaMRAhqOAKDaSHilxUI50zsYRtyrSjgu6HfREgCdHB55
xKMmVreBNfnSymuHmUY09Q8=
=fpbA
-----END PGP SIGNATURE-----
-- 
gentoo-portage-dev@g.o mailing list