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