Use as an independent library

[dralley]

I've seen the disclaimer:

If you are looking for an OpenPGP interface, consider using Sequoia, which this library is based on. If you want to use RPM’s OpenPGP interface, which you should only do if you are interacting with RPM, then you should link against RPM, which reexports this interface.

However, there are reasons that it would be nice to use this library independently. Perhaps as to integrate with something like rpm-rs or rpm-oxide, perhaps because you need to write software which interact with RPM package signatures but works on older OS' (where the old librpm may be problematic) or ones where librpm isn't readily available, perhaps you want a native Rust API (though, it doesn't appear that this currently exists).

Is this a hard statement about the intentions / goals of this library (i.e. don't expect this to ever be an independent, idiomatically-usable-from-Rust library), or just a way to set expectations about the current goals (i.e. right now, you should only use this via librpm)?

[nwalfield]

rpm's OpenPGP API is not great (see e.g., rpm-software-management/rpm#2041, and this thread). Initially we wanted to wholesale replace it, but because the OpenPGP API is part of rpm's public API, that would require an soname bump, which is not scheduled for a while. As such, we decided to reimplement the existing API in terms of Sequoia. In the future, we hope to completely redesign the API. The new API would not be rpm specific, but would be designed to also be used by other projects like dnf, ostree, etc. We'd like to get started on that as soon as possible, but without a sponsor like RedHat, we don't have the resources to undertake that project right now. Until that happens, if you need to use this API, but use it via librpmio.

[dralley]

Thanks for the response, makes sense!

[dralley]

Also note that since signing and verification functionality APIs are implemented in the aforementioned rpm-rs and rpm-oxide libraries, it might be useful to evaluate if one of them could be used as a starting point for the design.

It would be even better, if the implementation of certain bits of functionality could be shared completely between the three, or if the efforts converged a bit :)