Mailinglist Archive: opensuse-factory (826 mails)

< Previous Next >
Re: [opensuse-factory] RFC: Proposed relocation of /var/lib/rpm

sorry for top posting, but it is general feedback not specific to any part of
of email and pasting it in bottom is easy to overlook.

1. /usr/share/ sounds bad for me, as it can be often read-only FS ( e.g. on my
system it is ).

2. this snapshot and rollback make assumption that data in /var/lib is version
agnostic. Can you please specify on which data you make such assumption? I
think this is simply not true and just because we do not run it long enough we
do not face problems. But e.g. consider that mysql as part of update migrate
/var/lib/mysql to more efficient binary format and then you do rollback. Bum!
And e.g. with pgsql it is even more true, as it contain also part of
configuration. On my system is 62 entries in /var/lib and I am not sure if
every survive bigger downgrade of software that is using it.

According to this I suggest to instead move version agnostic data that should
not be snapshotted to own directory for which it is clear its purpose and have
such guarantie.


On Wed, 4 Oct 2017 13:16:58 +0200
Richard Brown <RBrownCCB@xxxxxxxxxxxx> wrote:

Hi all,

Currently, rpm stores its rpmdb (the record of all a systems packages)
in /var/lib/rpm

Various openSUSE & SUSE distributions have a number of problems with this

This has a major impact on our 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 most certainly don't want snapper rolling back a
database in /var/lib/mysql for example, and destroying user data in
the process.

Therefore we currently carry a rather complicated default list of subvolumes:

This list contains a number of specific directories in /var/* we wish
to preserve, which means it's almost continually out of date, leading
to user data being at risk if we haven't made a specific subvolume for
that data.

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 further complicated in *SUSE distributions that use a
Read-Only root filesystem (eg. openSUSE Kubic & SUSE CaaS Platform)
because it results in a situation where we really need to micromanage
countless subvolumes under /var - any location we miss otherwise ends
up read-only and packages can't write to the files they expect to be
able to in /var

Red Hat had a similar problem with their rpm-ostree tooling, which
they solved by relocating the RPM database to /usr/share/rpm

I would like to propose we adopt the same location for rpmdb in all
*SUSE distributions

This would mean we could make a single /var subvolume and dramatically
simplify our btrfs configuration

For systems with a read-only rootfs, /usr/share/rpm would be immutable
and pristine, just as we require it to be. Our tooling should already
be able to handle the new location without any major issues.

For systems with a read-write rootfs, we will be slightly bending the
rules of the FHS, in the sense that the FHS claims /usr should be
'read-only data'

However, installing packages routinely modifies the contents of /usr
and it's various subdirectories, that is the nature of installing

Therefore it seems logical to me that the record of what is installed
is also stored under the same conditions.

I'm working on a patchset in an OBS home project to test this proposal
and shake loose any issues, and will also be proposing this location
change to rpm upstream.

Therefore any comments are not only welcome, but the quicker the
better, so I can factor them into what I'm doing.

I would also like suggestions as how best to handle the migration of
an existing rpmdb in /var/lib/rpm to it's new location in
/usr/share/rpm, as I'm certain this is something we want to get
absolutely perfect, and I'm understandably nervous about changing the
rpmdb's location during an rpm transaction which will be altering the

Thanks in advance,

To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups