Let's split this into smaller pieces to move it forward. There are useful
commits in here that we can merge already, eg I think supporting key merge in
the keyring directly makes more sense than hiding it inside the import.
Basically, split commits 1-6 to another PR, just a few quick review-remarks:
- The commit messages could be more elaborate (these look like just something
quickly thrown there while working on something else, which was probably
exactly the case :sweat_smile: ). Eg, the RPMKEYRING_REPLACE fix, is that a
regression or what?
- Make rpmPubkeyRawData() return the pointer via return, and length via the
parameter. That's the common style in rpm API and returning void for something
that can fail is just weird and clunky for a caller who wants to check the
return.
- rpmKeyringIsEmpty() would be more general purpose as rpmKeyringSize() to
return number of keys in that keyring, it'll serve the empty check just as well
- The keystore name should probably be a property of the class, set from the
constructor of the base class. It seems fair that the keystores know who they
are, and then you don't need separate methods for each.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/3474#issuecomment-2547912087
You are receiving this because you are subscribed to this thread.
Message ID: <rpm-software-management/rpm/pull/3474/c2547912...@github.com>
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
https://lists.rpm.org/mailman/listinfo/rpm-maint
