| 1 |
On Sun, 2005-10-30 at 03:15 +0900, Jason Stubbs wrote: |
| 2 |
> On Sunday 30 October 2005 01:03, Ned Ludd wrote: |
| 3 |
> > The following simple patch adds the ability for to run a userside |
| 4 |
> > post_sync script, right now it's only used with rsync but the idea could |
| 5 |
> > be adopted rather easy for other methods of transfer that portage may |
| 6 |
> > use. The basic idea is to be able to preform a set of maintenance tasks |
| 7 |
> > right after sync up with an rsync server. Be that adding a call to svn |
| 8 |
> > co, cvs co, ebuild manipulation, updating search caches or other. I've |
| 9 |
> > been using this method on and off sense about portage-2.0.51.16 without |
| 10 |
> > any problems. Any comments before I file a bug for inclusion? |
| 11 |
> |
| 12 |
> This really goes hand in hand with the pre/post phase hooks patch. That patch, |
| 13 |
> however, implements hooks as bash functions rather than external executables. |
| 14 |
> The discrepancy there should probably be worked out before either are |
| 15 |
> included. Personally, I'm for the external executable method but I'm sure |
| 16 |
> that there will be alternative opinions... |
| 17 |
|
| 18 |
The pre/post hooks the way it's being worked out seems pretty ideal for |
| 19 |
it's purpose. Where this post_sync hook is an action hook vs a phased |
| 20 |
hook and we cant really source any files in. I'm thinking both ways are |
| 21 |
fitting for what they should do. |
| 22 |
|
| 23 |
One thing ferringb pointed out that is almost any call portage from the |
| 24 |
post_sync might make you spend a little extra time doing a regen. |
| 25 |
I don't see an ideal way to work around in the code and I'm thinking it |
| 26 |
might even be better in the case of dynamic ebuild manipulation done via |
| 27 |
the post_sync. However if you wanted to say have a call a |
| 28 |
/usr/bin/glsa-check -nl 2>/dev/null | /bin/sed -ne '/^[^[:space:]]\ |
| 29 |
+[[:space:]]\[N\]/p'glsa-check -l |
| 30 |
then we waste some extra time. |
| 31 |
|
| 32 |
He had also mentioned perhaps making the post sync a user definable |
| 33 |
variable and then spwaning as POST_SYNC="exec1:exec2:exec3". He pointed |
| 34 |
out that it would also open a hole in portage where it would look in |
| 35 |
profile dirs. |
| 36 |
|
| 37 |
|
| 38 |
-- |
| 39 |
Ned Ludd <solar@g.o> |
| 40 |
Gentoo Linux |
| 41 |
|
| 42 |
-- |
| 43 |
gentoo-portage-dev@g.o mailing list |
Archives