On Sat, 22 Jul 2006 16:52:38 -0700 Zac Medico <[EMAIL PROTECTED]> 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.
signature.asc
Description: PGP signature
