| 1 |
On 15 September 2014 13:30, Tim Harder <radhermit@g.o> wrote: |
| 2 |
|
| 3 |
> I haven't run portage metadata regen on a beefy machine lately, but I |
| 4 |
> don't think it could keep up in all cases. Perhaps someone can prove me |
| 5 |
> wrong. |
| 6 |
> |
| 7 |
> Anyway, things could definitely be sped up if portage merges a few speed |
| 8 |
> tweaks used in pkgcore. Specifically, I think using some of the weakref |
| 9 |
> and perhaps jitted attrs support along with the eclass caching hacks |
| 10 |
> would give a 2-4x metadata regen speedup. Otherwise pkgcore could |
| 11 |
> potentially be used to regen metadata as well or some other tuned regen |
| 12 |
> tool. |
| 13 |
> |
| 14 |
|
| 15 |
|
| 16 |
I generate metadata for the perl-experimental overlay periodically as a |
| 17 |
snapshotted variation of the same, and the performance isn't so bad. |
| 18 |
|
| 19 |
However, what I suspect you *could* do with a push hook is regen metadata |
| 20 |
for only things that were modified in that commit, because I believe |
| 21 |
there's a way to regen metadata for only specific files now. |
| 22 |
|
| 23 |
ie: |
| 24 |
modifications to cat/PN *would* trigger a metadata update, but only for |
| 25 |
that cat/PN |
| 26 |
modifications to eclass/* would *NOT* trigger a metadata update as part of |
| 27 |
the push. |
| 28 |
|
| 29 |
And doing tree-wide "an eclass was changed" updates could be done with |
| 30 |
lower priority in an asynchronous cron job or something so as not to block |
| 31 |
workflow for several minutes/hours/whatever while some muppet sits there |
| 32 |
watching "git push" do nothing. |
| 33 |
|
| 34 |
-- |
| 35 |
Kent |
| 36 |
|
| 37 |
*KENTNL* - https://metacpan.org/author/KENTNL |
Archives