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

[Mike Kelly]

On Sat, 22 Jul 2006 22:39:28 -0700
Brian Harring <ferringb@×××××.com> wrote:

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

True, adding hooks does have the potential for messing up some of the
internals of the ebuild. But, that is really a necessary part of their
operation; their whole point is that they can provide some indirect
access to that information to an external application.

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

Yes, I would like there to be some unified location for all these
hooks. At the moment, my hooks patch would only affect ebuild phases,
so it would have nothing to do with that post_sync hook, but I wouldn't
be adverse to extending the idea to other parts of portage.
 
> > I still think that those hooks should go into the tree rather than
> > being installed by packages.
>
> They're called eclasses ;)

The problem with having these in the tree is that they should be able
to take advantage of the unique features of each package manager.
Otherwise, they really are just eclasses.

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

Agreed, I would like to have better ability to clean up after myself.
However, this cleanup would be entirely dependent upon the current
implementation of my scripts, which could change at a different time
than a portage release - making my development stall because I won't be
able to make changes to one of the package managers I support.

Perhaps a simple ${EBUILD_PHASE}_fail hook could be added. For example,
change the pkg_${myarg} line to pkg_${myarg} || run_hooks ${myarg}
fail, where run_hooks is some theoretical function to run all the
proper hooks.

Although, once fully developed, the eselect utility for my particular
package should be able to check for these inconsistencies and repair
them afterwards.

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

Agreed. I'll be making a post to gentoo-dev shortly.

-- 
Mike Kelly
-- 
gentoo-portage-dev@g.o mailing list