Yes, it is the right value. However, the variant does not necessarily have to be present in the dict (in cases where there are no RPMs in the variant, the variant can still be included, see Silverblue on Fedora Rawhide as an example).

The emit function that calls this is itself called separately for binary, debug and source packages. This information could be passed to this function and only packages with matching category might be checked.

In general the change looks fine to me.

I'm not sure if the situation when the key doesn't match is handled well. in what situation do you want the command to silently not use the given key rather than giving you an error about key mismatch?

You're right. After thinking this over, let's fail with a non-zero exit code if the user specifies --gpg-key and any RPM is not signed with that key. This is security-sensitive code, so I think simplicity is better than "failing open" here.

Side note, I just found out Yum/DNF support multiple gpgkey URLs, https://unix.stackexchange.com/questions/215292/create-yum-repo-with-multiple-keys . I'll need to re-think the command-line argument UX here.

(Note to self, subscription-manager can write Yum repo files with multiple GPG keys, and the syntax for multiple GPG keys looks like this:)

gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release,file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-beta

Revisting this feature after some time, I can see I was trying to be way too clever with this feature.

I'll close this and open another PR with two simple declarative options:

1. --gpgcheck will be a boolean and cause the repo to have gpgcheck = 1 for all variants.
2. --gpgkey will take an arbitrary string.

And the "test if this compose is fully signed" logic should be another utility entirely, not compose-write-repo-file.