| 1 |
On 2014-09-14 21:57, Kent Fredric wrote: |
| 2 |
> I generate metadata for the perl-experimental overlay periodically as a |
| 3 |
> snapshotted variation of the same, and the performance isn't so bad. |
| 4 |
|
| 5 |
Overlays with few eclasses are much different than the main tree. |
| 6 |
Anyway, egencache isn't bad it's just significantly slower than |
| 7 |
alternatives so it could be sped up quite a lot if necessary. |
| 8 |
|
| 9 |
> However, what I suspect you *could* do with a push hook is regen metadata |
| 10 |
> for only things that were modified in that commit, because I believe |
| 11 |
> there's a way to regen metadata for only specific files now. |
| 12 |
|
| 13 |
> ie: |
| 14 |
> modifications to cat/PN *would* trigger a metadata update, but only for |
| 15 |
> that cat/PN |
| 16 |
> modifications to eclass/* would *NOT* trigger a metadata update as part of |
| 17 |
> the push. |
| 18 |
|
| 19 |
> And doing tree-wide "an eclass was changed" updates could be done with |
| 20 |
> lower priority in an asynchronous cron job or something so as not to block |
| 21 |
> workflow for several minutes/hours/whatever while some muppet sits there |
| 22 |
> watching "git push" do nothing. |
| 23 |
|
| 24 |
If we need to do piecewise regen it seems we would be better off just |
| 25 |
sticking with the current scheduled cron job approach. Otherwise it |
| 26 |
sounds like one could pull updates without having the correct metadata |
| 27 |
for a significant portion of the tree. |
| 28 |
|
| 29 |
Tim |
Archives