Presently a key imported (w 'rpm --import') will be accepted on every invocation and duplicates added.
This behavior is annoying, but is much worse when compounded with the inability to easily detect a key's presence. Though the fingerprint (appears) to be stored in the Version and Release fields, its not clear that this behavior is guaranteed nor is it easily scripted (presumably via zeroing a gpg keyring, importing, extracting signature of installed keys, and then comparing against RPM database).
The only other apparent alternative (incompletely listed in bug 76899 comment 2) would be to extract all keys, combine with desired import key, remove duplicates, and reimport. This is all rather silly compared to simply not importing a duplicate in the first place.
A replace-on-duplicate would be reasonable, however I would think a graceful-failure-on-duplicate would be preferable to avoid unnecessary write operations on the rpmdb.
Presently a key imported (w 'rpm --import') will be accepted on every invocation and duplicates added.
This behavior is annoying, but is much worse when compounded with the inability to easily detect a key's presence. Though the fingerprint (appears) to be stored in the Version and Release fields, its not clear that this behavior is guaranteed nor is it easily scripted (presumably via zeroing a gpg keyring, importing, extracting signature of installed keys, and then comparing against RPM database).
The only other apparent alternative (incompletely listed in bug 76899 comment 2) would be to extract all keys, combine with desired import key, remove duplicates, and reimport. This is all rather silly compared to simply not importing a duplicate in the first place.
A replace- on-duplicate would be reasonable, however I would think a graceful- failure- on-duplicate would be preferable to avoid unnecessary write operations on the rpmdb.