Note I don't care about transaction locking - everything rpm-ostree does is
always atomic. We create a new (hardlinked) tree, then a new rpmdb from
scratch every time.
---
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/52#issuecomment-1745
rpmdbOpen() and rpmdbAdd() are internal-only for a reason, for example they
bypass all sorts of things like transaction lock. However in rpm >= 4.12 there
is rpmtsImportHeader() which is essentially rpmdbAdd() wrapped with all the
necessary stuff.
---
Reply to this email directly or view it on
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 deal
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
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
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
I'm working on some custom rpm-ostree code to "install" rpms by
unpacking them with libarchive (since this can be a lot safer than
invoking librpm - my process has total control over writes), then just
using librpm to update the database via _JUSTDB.
However, it appears that for some reason that i
