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

[Mike Kelly]

On Mon, 24 Jul 2006 23:59:09 +0200
Marius Mauch <genone@g.o> wrote:

> On Mon, 24 Jul 2006 16:41:26 -0400
> Mike Kelly <pioto@×××××.org> wrote:
> > Basically, what I need to do is:
> >
> >  - Run a script to intelligently add / manage package manager-added
> >    users. At the moment, it would seem this should just be run
> > before or during the pkg_setup phase, but this may well be
> > sub-optimal, particularly in the case if binary packages or
> > non-standard ROOTs.
>
> can be done within an eclass.

Agreed. I don't think that I said this couldn't be.

> >  - Properly let that set of scripts know when an added user or group
> > is safe to remove. This code is intimately tied with the
> >    implementation-specific details of the above scripts, which may
> >    change from version to version, hence my trepidation about adding
> >    this code directly into portage itself.
>
> can be done with an eclass too. Also that eclass can depend on your
> scripts or whatever package it needs to do this, seems better than to
> add dependencies in every package using this functionality.
> Also should be able to have a generic interface for this.

Also agreed. And, I am going to try to thin down what code needs to be
run directly by the package manager. However, there is still the
limitation of the below.

> >  - Have the ability to clean up from myself if a build goes awry, or
> >    is aborted by the operator. As far as I know, this particular
> >    requirement would exclude the use of eclasses, but I could well
> > be wrong.
>
> Don't see how the proposed hook system would allow that either without
> additional mods in abort_handler.

Yeah, the patch I wrote last week won't do this. I'm working on such a
patch at the moment. However, am I correct in understanding that this
cannot be done from within an eclass? If so, I see that as one of the
stronger reasons for not using one. Having incomplete / unnecessary
user and group additions on a system is a bad thing for the package
manager to leave around.

> >  - Have this user addition handled in an intelligent way when we're
> >    only building/installing a binary package. I'm not really sure on
> >    what would be a logical way to do this.
>
> Yeah, that one is tricky.

Indeed. I'm still trying to figure out a reasonable way to handle it.
It seems at the moment that the user would need to be added on the
build system, and then later be added identically on the system where
it is ultimately installed on. Once building is done, the user could be
purged from the build system by something like an eselect module.

> > So, if the answer to the above is to not use some sort of hooks,
> > then I would appreciate pointers on where to look to achieve all of
> > the above with portage.
>
> Well, I'm not saying to not use hooks, just trying to find the (IMHO)
> best solution to the problem (and being a bit resistant against an
> generic unprotected hook system).
> From my POV this project should work like you provide a service (your
> management scripts) and portage/paludis/whatever use this service by
> calling the scripts. This would mean you wouldn't really have to care
> about the glue code but just provide an interface, and the pkgmanager
> has to conform to that interface.
> Right now it sounds like you want to work on the glue code, might be
> better to define the interface first.

At the moment, I think my interface is pretty well defined, although I
agree it could use a little more definition. I really want to try to
get some stable glue code set up, though, so that I can start testing
things out. Also, I want to have an idea of what the glue code is like,
as that dictates what sort of information my scripts can expect to have
available to them.

> Btw, you haven't really answered my question, what benefits do you/we
> get by having implementation specific hooks instead of using an
> eclass/repo level hook system (that "unique features" bit)?

Well, the main benefit I get by not using an eclass hook is that I can
properly clean up after myself if a build fails, and, I think, better
handle the addition of users in the case where the build and install
machines are different.

The more I look at this and discuss it with folks, I think that the
general hooks I suggested may not be adequate. Rather, I may just want
to prepare a patch which contains specific calls to my code at the
proper points.

My backend code isn't ready for prime time yet, so this stuff shouldn't
be in portage proper yet. Should I just be maintaining a patch in an
overlay for the time being and then work on getting this added in fully
at a later date?

Thanks all for the suggestions and for pointing out a few important
things to me.

-- 
Mike Kelly