[Rpm-maint] RFC: SUSE/openSUSE's proposed relocation of /var/lib/rpm
rbrown at suse.de
Mon Oct 9 15:25:51 UTC 2017
Hello rpm developers,
openSUSE & SUSE distributions have a growing number of problems with the current location of the rpmdb in
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
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.
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
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:
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
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
Thanks in advance,
Linux Distribution Engineer - Future Technology Team
Chairman - openSUSE
SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton,
HRB 21284 (AG Nürnberg)
More information about the Rpm-maint