The idea was to agree on the design first, and only once that agreement is
there, follow up with the (updated) implemenation. This is going the backwards
route again, and being painful because of that.
Your suggestion + updated PR is still based around the notion that there would
be data in multiple different keystores, but that's just not a legit use-case
AFAICS and I don't see anything proving the contrary here. Somebody doing
multiple imports with random different keyring definitions is not a use-case we
care about. Moving between different keystores is not an "end user" thing,
you're supposed to know what you're doing, including where your keys were
really. And, the pubkeys aren't precious data you can't afford to lose. The
worst case, you reimport them. They're much much less precious than the rpmdb
contents.
I really just want to see a 1:1 rebuild operation that supports arbityrary
src:dest combinations. The rebuild should follow the same exact semantics
whether src and dest differ or not. You shouldn't need a backend-specific
rebuild operation either.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3347#issuecomment-2547831234
You are receiving this because you are subscribed to this thread.
Message ID: <rpm-software-management/rpm/issues/3347/[email protected]>
_______________________________________________
Rpm-maint mailing list
[email protected]
https://lists.rpm.org/mailman/listinfo/rpm-maint
