1 |
On 11/06/2015 12:19 PM, Michał Górny wrote: |
2 |
> On Fri, 6 Nov 2015 11:49:44 -0800 |
3 |
> Zac Medico <zmedico@g.o> wrote: |
4 |
> |
5 |
>> On 11/06/2015 11:34 AM, Michał Górny wrote: |
6 |
>>> On Fri, 6 Nov 2015 10:58:23 -0800 |
7 |
>>> Zac Medico <zmedico@g.o> wrote: |
8 |
>>> |
9 |
>>>> On 11/06/2015 10:39 AM, Michał Górny wrote: |
10 |
>>>>> On Fri, 6 Nov 2015 09:24:15 -0800 |
11 |
>>>>> Zac Medico <zmedico@g.o> wrote: |
12 |
>>>>> |
13 |
>>>>>> On 11/06/2015 12:20 AM, Alexander Berntsen wrote: |
14 |
>>>>>>> On 06/11/15 09:05, Michał Górny wrote: |
15 |
>>>>>>>>>> I know nothing about the egencache stuff. Maybe Michał can |
16 |
>>>>>>>>>> comment? |
17 |
>>>>>>>> Michał finds this black magic. Trusts zmedico. |
18 |
>>>>>>> I think it looks like it's probably supposed to be reasonable, perhaps. |
19 |
>>>>>>> |
20 |
>>>>>>> Maybe Brian can look at it. At least that way we'll have a lot of |
21 |
>>>>>>> people that attempted understanding what's going on. |
22 |
>>>>>>> |
23 |
>>>>>>> Maybe we need a "Trusted-by:" line. |
24 |
>>>>>>> |
25 |
>>>>>> |
26 |
>>>>>> Maybe it helps if I give some more context. At my workplace, we have |
27 |
>>>>>> lots of scripts that call `emerge --sync private-work-repo` to ensure |
28 |
>>>>>> that the current system has the latest changes from private-work-repo. |
29 |
>>>>>> It can be annoying if it spends the bulk of its time calling hooks, even |
30 |
>>>>>> though private-work-repo was already up-to-date: |
31 |
>>>>>> |
32 |
>>>>>>>>> Timestamps on the server and in the local repository are the same. |
33 |
>>>>>>>>> Cancelling all further sync action. You are already up to date. |
34 |
>>>>>> |
35 |
>>>>>> So, we want to skip the hooks when repos are already up-to-date. In this |
36 |
>>>>>> case, there's no point in calling hooks or updating the metadata cache. |
37 |
>>>>> |
38 |
>>>>> This is incorrect assumption. A change in master repo may trigger |
39 |
>>>>> metadata cache update in slaved repo. |
40 |
>>>>> |
41 |
>>>> |
42 |
>>>> Good point. I'll update it to account for this. |
43 |
>>> |
44 |
>>> Please don't. This is just one of the corner cases when it will fail. |
45 |
>>> You can't assume any post-sync hook can be skipped if X or Y didn't |
46 |
>>> change. |
47 |
>> |
48 |
>> Can you give an example use case? It the sync operation did not change |
49 |
>> anything, then how is it useful to run hooks? |
50 |
> |
51 |
> I've already given you one example. I'm afraid there may be more |
52 |
> customized scripts where not being run is at least unexpected. The gain |
53 |
> is minor compared to the potential damage and confusion. |
54 |
> |
55 |
|
56 |
Yeah, I guess some people might be working under the assumption that |
57 |
emerge --sync will *always* call their hook, in order to trigger some |
58 |
system administration tasks that have little or nothing to do with the |
59 |
sync operation itself. It's impossible to speculate how many people |
60 |
might be relying on this sort of behavior. |
61 |
|
62 |
So, I'll think about exposing an environment variable to the hooks which |
63 |
will allow them to decide if anything relevant has changed. |
64 |
-- |
65 |
Thanks, |
66 |
Zac |