| 1 |
On Fri, 08 Sep 2006 14:57:16 -0700 |
| 2 |
"Vladimir G. Ivanovic" <vgivanovic@×××××××.net> wrote: |
| 3 |
|
| 4 |
> I run this script every hour: |
| 5 |
> |
| 6 |
> #!/bin/sh |
| 7 |
> glsa-check -f new 2>/dev/null |
| 8 |
> [[ $? -eq 0 ]] || echo "glsa-check: error" |
| 9 |
> |
| 10 |
> Does this not do what you're looking for? |
| 11 |
|
| 12 |
glsa-check draws its information from your local portage tree, so |
| 13 |
unless you are syncing hourly, too, it won't do you any good. |
| 14 |
|
| 15 |
|
| 16 |
On Thu, 7 Sep 2006 15:30:57 -0400 |
| 17 |
"Andy Dustman" <farcepest@×××××.com> wrote: |
| 18 |
|
| 19 |
> 2) Even with recent metadata cache update improvements, it still takes |
| 20 |
> a long time, and a lot of resources, to sync the tree. |
| 21 |
|
| 22 |
There are some other methods of syncing your tree which may or may not |
| 23 |
be faster for you, though. Take a look at emerge-webrsync (included |
| 24 |
with sys-apps/portage), and emerge-delta-webrsync (included in |
| 25 |
app-portage/emerge-delta-webrsync). |
| 26 |
|
| 27 |
The former pulls complete daily tarballs of the tree from a remote |
| 28 |
location. This may slower. |
| 29 |
|
| 30 |
The latter pulls patches instead of full tarballs. As I understand it, |
| 31 |
it's still fairly experimental, but it should, at least in theory, be |
| 32 |
much less network intensive than rsync. |
| 33 |
|
| 34 |
-- |
| 35 |
Mike Kelly |
Archives