Mailinglist Archive: opensuse-factory (826 mails)

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


Call me stupid, but why do we absolutely have to have btrfs? I mean I
really do not know enough about what BTRFS can do and what it can't do
to have any well funded opinion on that matter... but from following the
mailing lists I am getting the feeling that one of the biggest
"features" of btrfs is that it runs out of space quickly (snapshots)
when people get lots of updates often (TW, Plasma, Gnome from OBS).


I do believe that "we are not Red Hat" wouldn't really be the best reason.

Cheers,

Mathias


Am 04.10.2017 um 13:16 schrieb Richard Brown:
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:
https://en.opensuse.org/SDB:BTRFS#Default_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

https://rpm-ostree.readthedocs.io/en/latest/#why-not-implement-these-changes-in-an-existing-package-manager

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'

http://www.pathname.com/fhs/pub/fhs-2.3.html#THEUSRHIERARCHY

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

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
rpmdb.

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
References