Re: [gentoo-portage-dev] [PATCH] post_sync actions

[Brian Harring]

On Sun, Oct 30, 2005 at 01:02:43PM +0900, Jason Stubbs wrote:
> On Sunday 30 October 2005 09:32, Ned Ludd wrote:
> > On Sun, 2005-10-30 at 03:15 +0900, Jason Stubbs wrote:
> > > This really goes hand in hand with the pre/post phase hooks patch. That
> > > patch, however, implements hooks as bash functions rather than external
> > > executables. The discrepancy there should probably be worked out before
> > > either are included. Personally, I'm for the external executable method
> > > but I'm sure that there will be alternative opinions...
> >
> > The pre/post hooks the way it's being worked out seems pretty ideal for
> > it's purpose. Where this post_sync hook is an action hook vs a phased
> > hook and we cant really source any files in. I'm thinking both ways are
> > fitting for what they should do.
>
> The purpose of pre/post hooks is to allow user code to be run before/after a
> phase. What I'm asking is what benefits there are to requiring user hooks to
> be bash functions versus arbitrary executables.

They're stored in the env, easily accessible, and it replaces the 
bashrc functionality that ebd removes- that is what pre/post phase 
hooks do, and only that.

pre/post hooks as bash functions (inlined/sourced via bashrc) makes 
sense for that particular role.

A) the code has access to the local env (there's a major 
   difference between exported and local, most of the 
   interesting knobs are local)
B) the hooks have no way to influence the ebuild.sh env.  No, this is 
   not a pro, it detracts from what the hooks are intended for (direct 
   access into the env including the ability to blow your own foot 
   off).
C) user submission of bugs (especially when/if ebd hits) *will* include 
   the environment at some point.  We can see what they've inserted 
   into the hooks, and see if/how they screwed it up.  Doesn't work 
   that way for your proposed file approach, beyond telling them to 
   include the contents of their hooks directory.
   Still need the env for debugging however.
D) If they want to do seperate files, they can _if_ it's bashrc based.  
   It doesn't work the other way if it's file based.
E) Bashrc is a single point of entry, in other words a single point to 
   reach out and pull the appropriate functions dependant on cat/pkg.
   Split files == duplicated switching, which is not friendly to 
   users (keep it simple, less mistakes).

Hammering the point a bit further, the seperated file suggestion below 
*still* leaves bashrc in use, due to the fact chunked out pre/post 
phase hooks don't give you the ability to inspect/modify the env prior 
to portage even sourcing half it's functions.

bashrc route for pre/post is the most flexible and powerful route, and 
it should stay as it is.


> > He had also mentioned perhaps making the post sync a user definable
> > variable and then spwaning as POST_SYNC="exec1:exec2:exec3". He pointed
> > out that it would also open a hole in portage where it would look in
> > profile dirs.
>
> Something like:
> /etc/portage/hooks/post_sync
> /etc/portage/hooks/pre_src_unpack
> /etc/portage/hooks/post_src_compile
>
> seems more intuitive to me. The POST_SYNC variable would complicate portage
> code in the attempt to uncomplicate the user code (when more than one script
> is wanted to be ran). What I'm trying to figure out is why bashrc + post_sync
> is a better combination.

Not much for this obviously.  Aside from reasons above, changing the 
method people use for accessing the ebuild.sh env midstream without 
significant gain isn't good, plus it'll force any eclasses that need 
to do env resets (work around portage) to modify all of their ebuilds, 
rather then the route java eclasses were intended to take so the 1.4 
-> 1.5 could actually occur.

post sync has a limited shelf life; it's usable now for the following
1) rolling gensync functionality in
2) rolling glsa notices on sync in
3) rolling package watch lists of updates in
4) a method to trigger transfer of an rsync temp dir on a rsync proxy 
   for a lan to the actual directory rsyncd distributes from.

All of the above can be pulled off via aliasing/functions/custom 
scripts; what solar's patch implements is a way to inline it so people 
don't have to hack around missing functionality from portage, they can 
insert work arounds in the meantime.

Assume their is no question of what post sync will be (a target), 
unless you're advocating slipping that into the bashrc (which is a bad 
idea beyond pollution of the ebuild.sh env).

Maybe I've missed your point/question, which case feel free to 
disregard this email and clarify, but the question of how pre/post is 
implemented and why it should be this way I think I've laid out pretty 
well above.
~harring