[Rpm-maint] [rpm-software-management/rpm] rpmKeyringAddKey() should add subkeys too (Issue #3350)

[Panu Matilainen]

The refcounting locks are indeed broken there, always were. The main mutex is for the contents, refcounting is a different matter. We could probably just toss the nref locks out of the airlock and nothing would break...

One of the tools in solving loops is using weak dependencies. If all the keys and their subkeys are owned by the keyring from the go, then that alone guarantees they wont vanish up in the air, and then they don't need a thousand cross-references. And, I don't think we actually need primary key->subkey links for anything, just the subkey -> primary key link we already have.  The way this is all going it seems that we should just phase out all subkey business outside the keyring/key code itself. We can support rpmGetSubkeys() as long as it's there by just looking up the subkeys based on the primary key by brute force - it's not performance critical in any way.



-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3350#issuecomment-2405007075
You are receiving this because you are subscribed to this thread.

Message ID: <rpm-software-management/rpm/issues/3350/2405007075 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20241010/c9671e6c/attachment-0001.html>