Description of Problem: rpm --import the same key twice. The rpm db will have
two entries for the same key. You can only delete them by rpm -e --allmatches,
and re-import the same key again.
Version of selected component (if applicable): rpm-4.1-1.06
How Reproducible: every time
Steps to Reproduce:
1. # rpm --import /usr/share/doc/rpm-4.1/RPM-GPG-KEY
2. # rpm --import /usr/share/doc/rpm-4.1/RPM-GPG-KEY
3. # rpm -q gpg-pubkey
4. # rpm -e gpg-pubkey
5. # rpm -e gpg-pubkey --allmatches
rpm --import succeeds the second time
rpm -e gpg-pubkey fails because of multiple matches
rpm --import should fail (gracefully or silently) the second time.
Erase multiple entries with --allmatches, reimport
a single instance.
The real problem is distributing public keys
with packages, not fixing --import behavior.
I don't understand what you mean by "the real problem is distributing public
keys with packages" ?
The /usr/share/doc/rpm-4.1/RPM-GPG-KEY was only an example, I also have public
keys that I got from the webpages of authors and packagers. Previous versions of
rpm used the users gnupg keyring, so one could get keys from keyservers, but now
that rpm has its own internal "keyring", you can only import keys from files.
Anyway, I understand the WONTFIX, the -e -allmatches + re-import works (as I
said in the original report).
Using the package version as a counter would mean you could delete individual
copies, but that's not an elegant solution. Making rpm refuse to --import keys
that are already in the db would be cleaner IMHO.
The old behavior was better IMHO in some cases. At least you had only one place
with keyrings in the system. Current implementation is better when trying to
verify package on broken/compromited system. I underestand if this is the case.
rpmbuild still uses external gpg...
The better way could be an option to force use external program. The old
handling worked fine so why to drop it completly.
In the school the teacher told me that Unix uses external simple programs and
big programs with cumulated functions are not good (like sendmail)...