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 |