| 1 |
On Fri, Jul 6, 2018 at 3:02 PM Grant Edwards <grant.b.edwards@×××××.com> wrote: |
| 2 |
> |
| 3 |
> Now that the public key stuff is working again (knock on wood), I'm |
| 4 |
> curious if it's usual for an emerge --sync to take 10-15 minutes |
| 5 |
> longer than it used due to the "Verifying /usr/portage" step. |
| 6 |
> |
| 7 |
|
| 8 |
Again, the sync mechanisms are different, but I note that the git |
| 9 |
verify is nearly instant. |
| 10 |
|
| 11 |
Of course, the only thing being fed to gpg in the git case is the git |
| 12 |
commit record itself, which is about 10 lines of text. That record |
| 13 |
contains a content hash of the tree record, which in turn references |
| 14 |
content hashes of every directory inside, and so on. So, with git |
| 15 |
most of the hash validation is happening constantly just by virtue of |
| 16 |
everything being content-hashed, and the only extra layer with the gpg |
| 17 |
signature is to sign the top level of the whole tree. |
| 18 |
|
| 19 |
Now, on the flip side, some of those git operations might take time |
| 20 |
since it is stating files for things like git status/etc. I've never |
| 21 |
noticed an issue, but I'm also on an SSD and tend to always have a |
| 22 |
warm cache when I'm using it. emerge shouldn't need to trigger any |
| 23 |
git operations except when syncing. |
| 24 |
|
| 25 |
-- |
| 26 |
Rich |
| 27 |
|
| 28 |
|
| 29 |
|
| 30 |
-- |
| 31 |
Rich |
Archives