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
choice.
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
/usr/sysimage
...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 -
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
