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

[Marius Mauch]

On Sat, 22 Jul 2006 16:52:38 -0700
Zac Medico <zmedico@g.o> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Mike Kelly wrote:
>
> > 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.

I still think that those hooks should go into the tree rather than
being installed by packages. That's mainly so they get increased
visibility and gives us (us being Gentoo, not just Portage) more
access and control over them, like we have with eclasses.

This also moves responsibility from hook authors to pkgmanager authors
(the package mamanger has to support the hook format in the tree, not
the hook has to support (all of) the specific package manager hook
formats). I know Mike has taken care of Paludis support already, but
look at a larger scale:
a) n hook authors supporting m package manager interfaces: O(n*m)
b) n hook authors and m package managers supoprting one repository
interface: O(n+m)
Also with a) you have to play what I call the "catch up game", e.g. a
new package manager gets out and all hooks have to account for a new
interface (even if it's just a new path).
Of course a) has the "drawback" that it requires a solid spec of the
interface, but that's something we want anyway.

However, *if* they are going to be installed by packages they should go
either into /etc/portage/foobar or /usr/lib/portage/foobar (like any
3rd party elog or cache modules), foobar being something we'd have to
decide on.
The suggested /var/libexec/portage has several issues:
- /var/libexec is AFAIK not defined by FHS
- executable data doesn't belong in /var unless it's application data
which isn't the case here
- libexec generally sucks (even in /usr), especially as we already
use /usr/lib for what generally goes there (support scripts)

Independent on the location I'd like to see the ability to blacklist
individual hooks for testing, troubleshooting, debugging and probably a
few other reasons. And no, this should not be done with $FEATURES ;)

Marius

-- 
Public Key at http://www.genone.de/info/gpg-key.pub

In the beginning, there was nothing. And God said, 'Let there be
Light.' And there was still nothing, but you could see a bit better.