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

[Brian Harring]

On Sun, Jul 23, 2006 at 06:09:31AM +0200, Marius Mauch wrote:
> 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.

Lemme see if I follow this.  The build execution *was*-
Start of 2.0.51:
pkg_setup
src_unpack
src_compile
src_test (feature controlled)
src_install
pkg_preinst
pkg_postinst

Start of 2.1:
pre_pkg_setup     (user controlled)
pkg_setup
post_pkg_setup    (user controlled)
pre_src_unpack    (user controlled)
src_unpack
post_src_unpack   (user controlled)
pre_src_compile   (user controlled)
src_compile
post_src_compile  (user controlled)
pre_src_test      (user and feature controlled)
src_test          (feature controlled)
post_src_test     (user and feature controlled)
pre_src_install   (user controlled)
src_install
post_src_install  (user controlled)
pre_pkg_preinst   (user controlled)
pkg_preinst
post_pkg_preinst  (user controlled)
pre_pkg_postinst  (user controlled)
pkg_postinst
post_pkg_postinst (user controlled)


And what is being suggested is:
pre_pkg_setup     (system controlled)
pre_pkg_setup     (user controlled)
pkg_setup
post_pkg_setup    (user controlled)
post_pkg_setup    (system controlled)
pre_src_unpack    (system controlled)
pre_src_unpack    (user controlled)
src_unpack
post_src_unpack   (user controlled)
post_src_unpack   (system controlled)
pre_src_compile   (system controlled)
pre_src_compile   (user controlled)
src_compile
post_src_compile  (user controlled)
post_src_compile  (system controlled)
pre_src_test      (system and feature controlled)
pre_src_test      (user and feature controlled)
src_test          (feature controlled)
post_src_test     (user and feature controlled)
post_src_test     (system and feature controlled)
pre_src_install   (system controlled)
pre_src_install   (user controlled)
src_install
post_src_install  (user controlled)
post_src_install  (system controlled)
pre_pkg_preinst   (system controlled)
pre_pkg_preinst   (user controlled)
pkg_preinst
post_pkg_preinst  (user controlled)
post_pkg_preinst  (system controlled)
pre_pkg_postinst  (system controlled)
pre_pkg_postinst  (user controlled)
pkg_postinst
post_pkg_postinst (user controlled)
post_pkg_postinst (system controlled)


May I ask what the next revision shall be?  Because I'd expect the 
next request to be a post user hook, hook; that way any the author can 
ensure that the they're changes are last (till users bitch, and 
request their own hook that is last in the stacking).

Sarcasm aside, hopefully y'all see the point that hooks have their own 
issues, and one cannot just slap more hooks in without considering the 
resultant mess (bluntly).


> I still think that those hooks should go into the tree rather than
> being installed by packages.

They're called eclasses ;)

If after transferring that level of control to the tree, then my 
original suggestion (from way the hell back) of moving the actual 
ebuild template into the tree should be taken; fundamentally, no 
different; eapi actually sets it up better.


> 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.

Eclasses exist already... base ebuild template is effectively an 
eclass also, shove that into the tree and modify it rather then 
further phase expansion (although I poke a hole in that below).


> 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.

It also has the drawback that via transferring control over to the 
tree, the pkg manager cannot do proper cleanup.

What you say?

What happens if $PKGMANGER adds user blah for building xyz, xyz fails?  
Proper course of action would be to punt this unused user if it's 
refcount is just xyz, no?
  
Transfer control of fundamental features like that to delegation 
hooks, you either have to add more hooks so the delegation target can 
cleanup after itself, or you plain don't do cleanup.

So... pretty much I'm saying that at least my usage of dynusers, I 
won't be supporting the hook route- reasons were given above.  Funny 
thing is that pkgcores support would be _better_, but wouldn't be 
considered 'compliant' because of the intended decrees above.

What other hooks are actually required?

And finally, I'd suggest this get ran past devs in general- expanding 
the phase hooks for ebuilds (this is just that) isn't something that 
should be done lightly; the original pre/post were done as a 
concession to users for an upcoming (at the time) breakage of their 
existing functionality, not as an actual phase expansion for ebuilds 
to use (yes java eclass uses it, but their usage of it would die at 
the exact moment the env issues were fixed).

~harring