On 3/13/19 3:33 AM, Miroslav Suchý wrote:
Dne 12. 03. 19 v 19:49 Kevin Fenzi napsal(a):
> We need to revamp this entirely, and as luck would have it, we have a plan:
>
>
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
I am afraid that this will not help in this situation, because even if $releasever will
be equal to "rawhide" you still
will have in repo file:
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch>
which will have prior the branching *content* of F30 gpg key. Then after branching (let
say 4 weeks later) you will run
'dnf upgrade'. It will try to download new fedodra-gpg-keys package, which will
be signed by F31 gpg key.
Yeah.
IMO the only solution to this is:
* create new gpg keys several months before branching and add it to fedodra-gpg-keys
package and
Yep. We should do this, but note that this only partly solves it. What
if I have a rawhide machine from when rawhide was f29 say or older and
decide to try and update it? :) Of course you should always update your
rawhide machines frequently.
but it would help. We could even just generate them always at least a
release in advance. ie, make sure the f32 key goes out with f30.
* gpgkey in repo file lists both gpg keys
So, you mean current rawhide should list the f31 key and the (not yet
made) f32 key? yeah, we could do that I think. I haven't tested, but man
dnf.conf implies you can specify multiple keys per repo.
or
* sign rpm packages in rawhide by both keys - and I'm afraid our infrastructure is
not ready for this.
I persued this. Our infrastructure is fine with it... but rpm isn't.
https://github.com/rpm-software-management/rpm/issues/189
kevin