There are multiple reports of intermittent key refresh failures: bug 647696 bug 648586 https://forums.gentoo.org/viewtopic-p-8179992.html#8179992 https://forums.gentoo.org/viewtopic-p-8185252.html#8185252 https://forums.gentoo.org/viewtopic-p-8188376.html#8188376 https://forums.gentoo.org/viewtopic-p-8190196.html#8190196
What's it supposed to do? Bash the server in the hope some attempt will succeed? If the servers are having problems, then servers need to address that. Gemato does key refresh as the very first thing it does. So does current portage.git (it refreshes keys even before doing rsync). If someone wants to retry, he can run the command again.
Are you suggesting that portage should call gemato multiple times until it succeeds? I'm afraid that's not acceptable.
If gemato doesn't have the ability to retry the gpg key refresh, then portage is going to have to do it. Every thing that network client thing that portage does needs retry support.
Portage *does not* call gemato. It uses its API. This API includes refresh_keys() method. As the name says, it refreshes keys *once*. I won't turn it into bash_the_server_until_it_bans_you().
(In reply to Michał Górny from comment #4) > Portage *does not* call gemato. It uses its API. I was thinking in terms of portage-2.3.24 which calls the gemato binary, and is due for stabilization soon. I suppose we can disable the rsync-verify USE flag default, until we have retry / backoff support integrated into portage. > This API includes refresh_keys() method. As the name says, it refreshes keys > *once*. I won't turn it into bash_the_server_until_it_bans_you(). That's fair enough, I see that it raises an OpenPGPKeyRefreshError that portage can handle. Thanks for the info!
