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