Re: [Rpm-maint] [rpm] te: Don't reload header for JUSTDB transactions (#52)
I ended up storing lead/sig/header in the ostree commit, then checking it out as a tempfile and passing it back to librpm. So we can close this. Long term, I think what I really want is to make `rpmdbOpen` and `rpmdbAdd` public. Then I can stay out of the business of writing to the db and dealing with berkeleydb, but know I have total control over everything else. --- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/52#issuecomment-174322177___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm] te: Don't reload header for JUSTDB transactions (#52)
Closed #52. --- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/52#event-524294958___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm] te: Don't reload header for JUSTDB transactions (#52)
Rpm needs to reload the header because to conserve memory, it doesn't preserve the original at all. --- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/52#issuecomment-173868086___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm] te: Don't reload header for JUSTDB transactions (#52)
Ideally, we just let `mmap()` handle that. That's what OSTree does for metadata by default. It'd probably work for packed RPMs as well...except in practice we byteswap in `regionSwab()` so require a writable mapping =/ For OSTree, GVariant handles a lot of this automatically for interior data, for "exterior" integers we just byteswap on access. Anyways, one option I looked at would be for OSTree to store *everything* from the original RPM (lead, signature, header), then attempt to re-synthesize it from the ostree commit when RPM asks for it. Downsides: - A pipe-to-self is just ugly and inefficient - I think I'd have to parse the RPM myself to accurately extract the start of the cpio stream Positives: - We'd also store the original gpg sigs I guess regardless, it'd be nice if RPM supported (somehow) a mode where the calling application could optionally provide just a `Header` reference, not a full fd to an RPM. --- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/52#issuecomment-173925491___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
