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
pgprdKZL9j3SB.pgp
Description: PGP signature
