| 1 |
Joby Walker said: |
| 2 |
|
| 3 |
>>>2) Not running 'emerge sync' from each server is actually harmful to the |
| 4 |
>>>server. You might be able to use 'emerge regen' to mitigate most of |
| 5 |
>>>this, but I haven't investigated it that fully (since I switched from |
| 6 |
>>>NFS /usr/portage to a BINHOST). |
| 7 |
>> |
| 8 |
>> Any chance you could expand on this more? It's starting to sound like it |
| 9 |
>> may be more difficult than expected to maintain a central |
| 10 |
>> portage/package |
| 11 |
>> source for all of our servers. |
| 12 |
>> |
| 13 |
> |
| 14 |
> An "emerge sync" runs a lot of maintenance on the /var/db/pkg and |
| 15 |
> /var/cache/edb directories. As packages are relabeled or recategorized, |
| 16 |
> "emerge sync" re-orgs your /var caches to reflect the new structure. If |
| 17 |
> this maintenance doesn't happen you will start getting dependancy errors |
| 18 |
> when trying to install a package. This happened to me with Perl. |
| 19 |
|
| 20 |
So, if each system should have emerge sync ran on it to keep these caches |
| 21 |
in good shape, then /usr/portage will be updated on each host too. If the |
| 22 |
administrators of these other hosts decide to (or forget the process), |
| 23 |
they could bypass our package server and freely install from their own |
| 24 |
local portage tree. |
| 25 |
|
| 26 |
But that might not be a real concern. As long as BINHOST is honored, |
| 27 |
binary packages from the master server will still be used. /usr/portage |
| 28 |
will be basically unused in this case, but still maintained. |
| 29 |
|
| 30 |
I guess we're just not lessening the need to avoid maintaining |
| 31 |
/usr/portage on each host. Is there no way to do that? |
| 32 |
|
| 33 |
It might not be a big deal, if we make sure that our build server is the |
| 34 |
source for these syncs. |
| 35 |
|
| 36 |
DS |
Archives