| 1 |
On Fri, 6 Nov 2015 09:24:15 -0800 |
| 2 |
Zac Medico <zmedico@g.o> wrote: |
| 3 |
|
| 4 |
> On 11/06/2015 12:20 AM, Alexander Berntsen wrote: |
| 5 |
> > On 06/11/15 09:05, Michał Górny wrote: |
| 6 |
> >>>> I know nothing about the egencache stuff. Maybe Michał can |
| 7 |
> >>>> comment? |
| 8 |
> >> Michał finds this black magic. Trusts zmedico. |
| 9 |
> > I think it looks like it's probably supposed to be reasonable, perhaps. |
| 10 |
> > |
| 11 |
> > Maybe Brian can look at it. At least that way we'll have a lot of |
| 12 |
> > people that attempted understanding what's going on. |
| 13 |
> > |
| 14 |
> > Maybe we need a "Trusted-by:" line. |
| 15 |
> > |
| 16 |
> |
| 17 |
> Maybe it helps if I give some more context. At my workplace, we have |
| 18 |
> lots of scripts that call `emerge --sync private-work-repo` to ensure |
| 19 |
> that the current system has the latest changes from private-work-repo. |
| 20 |
> It can be annoying if it spends the bulk of its time calling hooks, even |
| 21 |
> though private-work-repo was already up-to-date: |
| 22 |
> |
| 23 |
> >>> Timestamps on the server and in the local repository are the same. |
| 24 |
> >>> Cancelling all further sync action. You are already up to date. |
| 25 |
> |
| 26 |
> So, we want to skip the hooks when repos are already up-to-date. In this |
| 27 |
> case, there's no point in calling hooks or updating the metadata cache. |
| 28 |
|
| 29 |
This is incorrect assumption. A change in master repo may trigger |
| 30 |
metadata cache update in slaved repo. |
| 31 |
|
| 32 |
-- |
| 33 |
Best regards, |
| 34 |
Michał Górny |
| 35 |
<http://dev.gentoo.org/~mgorny/> |
Archives