Gentoo Archives: gentoo-portage-dev

From: Jason Stubbs <jstubbs@g.o>
To: gentoo-portage-dev@l.g.o
Subject: Re: [gentoo-portage-dev] [PATCH] post_sync actions
Date: Sun, 30 Oct 2005 05:47:54
Message-Id: 200510301447.51733.jstubbs@gentoo.org
In Reply to: Re: [gentoo-portage-dev] [PATCH] post_sync actions by Brian Harring
1 On Sunday 30 October 2005 14:27, Brian Harring wrote:
2 > On Sun, Oct 30, 2005 at 01:02:43PM +0900, Jason Stubbs wrote:
3 > > On Sunday 30 October 2005 09:32, Ned Ludd wrote:
4 > > > On Sun, 2005-10-30 at 03:15 +0900, Jason Stubbs wrote:
5 > > > > This really goes hand in hand with the pre/post phase hooks patch.
6 > > > > That patch, however, implements hooks as bash functions rather than
7 > > > > external executables. The discrepancy there should probably be worked
8 > > > > out before either are included. Personally, I'm for the external
9 > > > > executable method but I'm sure that there will be alternative
10 > > > > opinions...
11 > > >
12 > > > The pre/post hooks the way it's being worked out seems pretty ideal for
13 > > > it's purpose. Where this post_sync hook is an action hook vs a phased
14 > > > hook and we cant really source any files in. I'm thinking both ways are
15 > > > fitting for what they should do.
16 > >
17 > > The purpose of pre/post hooks is to allow user code to be run
18 > > before/after a phase. What I'm asking is what benefits there are to
19 > > requiring user hooks to be bash functions versus arbitrary executables.
20 >
21 > They're stored in the env, easily accessible, and it replaces the
22 > bashrc functionality that ebd removes- that is what pre/post phase
23 > hooks do, and only that.
24 >
25 > pre/post hooks as bash functions (inlined/sourced via bashrc) makes
26 > sense for that particular role.
27 >
28 > A) the code has access to the local env (there's a major
29 > difference between exported and local, most of the
30 > interesting knobs are local)
31 > B) the hooks have no way to influence the ebuild.sh env. No, this is
32 > not a pro, it detracts from what the hooks are intended for (direct
33 > access into the env including the ability to blow your own foot
34 > off).
35 > C) user submission of bugs (especially when/if ebd hits) *will* include
36 > the environment at some point. We can see what they've inserted
37 > into the hooks, and see if/how they screwed it up. Doesn't work
38 > that way for your proposed file approach, beyond telling them to
39 > include the contents of their hooks directory.
40 > Still need the env for debugging however.
41 > D) If they want to do seperate files, they can _if_ it's bashrc based.
42 > It doesn't work the other way if it's file based.
43 > E) Bashrc is a single point of entry, in other words a single point to
44 > reach out and pull the appropriate functions dependant on cat/pkg.
45 > Split files == duplicated switching, which is not friendly to
46 > users (keep it simple, less mistakes).
47 >
48 > Hammering the point a bit further, the seperated file suggestion below
49 > *still* leaves bashrc in use, due to the fact chunked out pre/post
50 > phase hooks don't give you the ability to inspect/modify the env prior
51 > to portage even sourcing half it's functions.
52 >
53 > bashrc route for pre/post is the most flexible and powerful route, and
54 > it should stay as it is.
55
56 This is what I was after and is clear.
57
58 > post sync has a limited shelf life; it's usable now for the following
59 > 1) rolling gensync functionality in
60 > 2) rolling glsa notices on sync in
61 > 3) rolling package watch lists of updates in
62 > 4) a method to trigger transfer of an rsync temp dir on a rsync proxy
63 > for a lan to the actual directory rsyncd distributes from.
64
65 1, 2 and 3 are slated for inclusion. What will happen with 4 and other similar
66 site-specific hooks?
67
68 > Assume their is no question of what post sync will be (a target),
69 > unless you're advocating slipping that into the bashrc (which is a bad
70 > idea beyond pollution of the ebuild.sh env).
71
72 Heh. No question at all on the post sync side. ;)
73
74 --
75 Jason Stubbs
76 --
77 gentoo-portage-dev@g.o mailing list

Replies

Subject Author
Re: [gentoo-portage-dev] [PATCH] post_sync actions Brian Harring <ferringb@g.o>