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.
This request was evaluated by Red Hat Engineering for inclusion in a Red Hat Enterprise Linux maintenance release.
Red Hat does not currently plan to provide this change in a Red Hat Enterprise Linux update release for currently deployed products.
With the goal of minimizing risk of change for deployed systems, and in response to customer and partner requirements, Red Hat takes a conservative approach when evaluating enhancements for inclusion in maintenance updates for currently deployed products. The primary objectives of update releases are to enable new hardware platform support and to resolve critical defects.
However this has been fixed in Red Hat Enterprise Linux 6, where rpm no longer imports duplicate keys.
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.