[Rpm-maint] [rpm-software-management/rpm] RFE: container-native rpmdb format (Issue #2005)

Robert Sturla notifications at github.com
Wed Dec 10 16:40:25 UTC 2025


p5 left a comment (rpm-software-management/rpm#2005)

> > Each installed RPM is represented by a numbered file in /var/lib/rpm/jsonzstd,
> 
> This should be in the default %_dbpath which shouldn't be /var except on RHEL <= 9.

I will make that change!  Though please note that I have encountered different problems with the implementation (nothing major, just due to lack of understanding of the codebase/existing backend) which prevented signature verification to work.  I do want to pick this back up and make something fully functional but I don't believe I can contribute back here due to the AI policy and my limited C knowledge.

> > In the same directory lives a "manifest" file which points to each individual package file and stores metadata about the next number in the sequence.
> 
> Is the sequence defined by package installation order for a fresh image? And then subsequent ones use N+1 starting from the last?

Exactly.  Similar to the current sqlite backend, the order of the database (in this case the files) is determined by the order the packages were installed.  Thought this made the most sense given the scriptlets being invoked in different orders could result in filesystem differences.

The manifest file could be done away with, but I liked the thought of leaving a blank number where a package is removed which requires storing the next available value in a file.

With regards to the sysext use-case, definitely!  I had not considered that use-case, I was more thinking about derived container images.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2005#issuecomment-3637984052
You are receiving this because you are subscribed to this thread.

Message ID: <rpm-software-management/rpm/issues/2005/3637984052 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20251210/225ab580/attachment.htm>


More information about the Rpm-maint mailing list