Move internal OpenPGP parser into a subdirectory #2704
Conversation
|
To elaborate, the idea here is to split the new rpmpgp subdirectory into a separate repository that can be pulled into the build for the "internal pgp" support, but to eliminate it from the rpm repo and release tarballs. This resolves #2414 as far as I'm concerned. @mlschroe , you indicated interest in maintaining the parser in #2414 - do you still think that way, and does this split look like you could work with? @nwalfield - just fyi. |
|
If we add new functions to the API, as suggested recently in this issue, then the internal implementation will need to be updated. This will require a versioning scheme for the API, I think, which would complicate maintenance. Alternatively, we say we don't support the internal API at all. What do you think? |
|
Having more modules does indeed complicate things, but then we're already in a situation where we need to coordinate any API additions between rpm and rpm-sequoia. It just hasn't really come up yet because ATM we're just bumping the required rpm-sequoia version as we go, but at some point we'll probably need to allow for more freedom (for older versions and such). I basically see this as another step on our way to drop support for the internal parser entirely, I have a hard time seeing the development on it "taking off" due to the split. And if I'm proven wrong on that, then I guess it shouldn't have trouble keeping up with the new APIs either. |
This will let us split it out of the main rpm repository with minimal effects to the outside. Make sure the name implies its status too. Ie, first we declared it's trash, and now we're swiping it under the carpet.
pmatilai
force-pushed
the
pgpdir
branch
2 times, most recently
from
77c7139
to
c289eba
Compare
|
Tweaked a little bit to make the legacy status more prominent in the naming. |
This will let us split it out of the main rpm repository in the next steps.
Ie, first we declared it's trash, and now we're swiping it under the carpet.