[Rpm-maint] RFC: SUSE/openSUSE's proposed relocation of /var/lib/rpm

Panu Matilainen pmatilai at redhat.com
Thu Oct 12 11:18:19 UTC 2017

On 10/09/2017 06:25 PM, Richard Brown wrote:
> Hello rpm developers,
> openSUSE & SUSE distributions have a growing number of problems with the current location of the rpmdb in
> /var/lib/rpm
> All *SUSE Distributions have a default btrfs snapshot & rollback feature.
> We need the contents of the rpmdb contained within the snapshots.
> This means /var/lib/rpm must be contained in the root snapshot in order to preserve the "system-state";
> Without it a rolled-back system still thinks it has packages installed/removed which were changed as a result
> of the rollback.
> But /var and /var/lib both contain a great deal of data which we DO NOT want to include in the root snapshot;
> For example, we dont want to roll back a database in /var/lib/mysql for example, destroying user data in the
> process.
> Therefore we currently carry a rather complicated default list of btrfs subvolumes and lots of other similarly
> cludgy hacks. If we don't continually update this list for every package we carry, user data is at risk. User
> data is almost always at risk for any 3rd party package putting data in /var/*
> The rpmdb is the only "system-state" information we have in /var which we need to preserve, making it quite a
> disruptive presence in the /var filesystem hierarchy.

Yeah, it's an interesting thing - it's not the obvious "variable data" 
that it initially seems once you stop to actually think about it: except 
for the locks and other runtime bookkeeping, the metadata in rpmdb is 
exactly as invariable as the data it concerns, mostly /usr.

> The problem is exacerbated in *SUSE distributions that use a Read-Only root filesystem (we have several now).
> We are often ending up with packages unable to write to places in /var they expected to be able to, but can't
> because we're taking care to treat /var/lib/rpm the same as we do the rest of the RO rootfs.
> Red Hat had a similar problem with their rpm-ostree tooling, which they solved by relocating the RPM database
> to /usr/share/rpm
> https://rpm-ostree.readthedocs.io/en/latest/#why-not-implement-these-changes-in-an-existing-package-manager
> Therefore we're also considering changing where we store the rpmdb in all *SUSE distributions
> We've been discussing this at length on our lists:
> https://lists.opensuse.org/opensuse-factory/2017-10/msg00047.html
> The discussion currently boils down to either copying rpm-ostree and placing our rpmdb in /usr/share/rpm, or
> locating it in /usr/lib/rpmdb
> Within our community there is a strong argument against /usr/share is predominantly because it is the most-
> likely part of the /usr hierarchy that is going to be shared, and is clearly documented that it should be
> "architecture independent data" - something which the cannot be said to be true of the rpmdb, which is
> certainly architecture specific.
> Meanwhile, storing it in /usr/lib can be argued to be consistent with the FHS. The rpmdb can be argued to be
> 'object files' used by rpm.
> While /usr is meant to be readonly and the rpmdb it isn't strictly 'read-only', the reality is that on an rpm
> managed system, packages will be installing binaries, libs, and god knows what else within /usr.
> Therefore it seems acceptable that the database tracking that is also present in /usr.
> There is a desire to avoid piling more data in the already busy /usr/lib/rpm, therefore the current leaning
> within the openSUSE Project (and SUSE for SLE) is to patch our rpm package to use /usr/lib/rpmdb as our dbpath
> going forward
> But I'd like to hear the opinions of this list as rpm's upstream.
> In an ideal world I'd also like this change considered for adoption upstream, but obviously that isn't
> something to be considered lightly.
> Product timetables are likely to force SUSE/openSUSE to adopt one of the above options relatively soon, so any
> quick feedback and thoughts will be greatly appreciated.
> What do you all think? And if a change like this is on the cards as an rpm default, where would the likely
> location be?

I agree /usr/share seems entirely wrong, because the whole point of 
/usr/share is to be shareable across multiple architectures and an rpmdb 
certainly is not.

I dont like the idea of cramming it into /usr/lib/rpm either because the 
rpmdb content is entirely different in nature from the other things in 
there. And like you said, it's busy enough as it is.

So between these alternatives, I think /usr/lib/rpmdb is the least worst 

However I'd hope we could do better than "least worst".

The FHS in its current incarnation is a product of a different era of 
computing really. When it doesn't cover some modern need adequately, I 
don't really see how it's better to hold your nose and forcefully bend 
one of its definitions to fit a particular purpose than invent something 
new that actually fits.

Rpm is not the only data of this kind, I can think of at least one other 
similar need (SWID) and almost certainly there are more. Why not give 
this data a place of its own? Something like


...which can be defined to suit the actual need for this type of system 
specific data, and under which rpm or rpmdb name would fit just fine.

As for changing the actual rpm default to something else, we can't just 
flip the macro to another directory, the transition for existing systems 
would need to be handled somehow. One possibility might be turning 
%_dbpath into a PATH-like search path, new location first and 
/var/lib/rpm last and and have --rebuilddb move the database into the 
first path of the list.

	- Panu -

More information about the Rpm-maint mailing list