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

Richard Brown rbrown at suse.de
Mon Oct 16 15:22:15 UTC 2017

On Fri, 2017-10-13 at 11:31 +0300, Panu Matilainen wrote:

> The database path has always been trivially configurable with a macro 
> without having to patch rpm, nobody is taking that away. And because 
> it's so trivial to change it really doesn't need a configure switch either.
> It's also way, way early to discuss about changing defaults. For that, 
> there needs to be at least
> a) a viable new location (which is what I think this discussion is about)

And unless I'm reading the thread wrong so far, the consensus seems to be that /usr/lib/rpmdb is a viable new
location for those who have use cases where /var is problematic.

Also it seems to be generally agreed that is arguably 'more viable' than options like /usr/share/rpm

Does anyone feel I'm reading the feeling of the list wrong, or does anyone have a different opinion?

> b) a way to handle migration in a reasonably transparent manner

In openSUSE/SLE we're going to handle this in the spec file for our rpm package.


To describe it simply, we're doing the following

- in %post, if we identify that /var/lib/rpm is not a symlink & contains a rpmdb, we create a symlink for
/usr/lib/rpmdb to the existing db. This ensures any scriptlets or such calling 'rpm' in the same transaction
will still be able to read their database.

- in %posttrans, if we identify that /var/lib/rpm is not a symlink & contains an rpmdb, we remove the
/usr/lib/rpmdb symlink made in %post, create a folder, and mv the db to that folder. We then rmdir
/var/lib/rpm and replace it with a symlink to the new /usr/lib/rpmdb location

And that's it. It's proven to be reasonably transparent in all of my testing thusfar, though as this change is
now on the way to openSUSE Tumbleweed it's possible something will shake loose.

Thoughts/Comments/Feedback welcome.

As rpm doesn't provide an example specfile and leaves things like database initialisation to distributions, I
suppose the best way would be to document the above method for those relocating their rpmdb.

Where/how would be the best way for me to do that?

> c) a reason with actual benefits to majority of users (that's what 
> *defaults* are about)

While the rpm-ostree and snapper use cases hit against this most painfully, I actually don't buy the argument
that the majority of users would not benefit from this change.
I've been administering rpm managed systems for more years than I'd like to count, and /var/lib/rpm has often
been the only thing in /var which I've had to pay extra attention to when backing up and restoring a system.

I personally think having the rpmdb under /usr will dramatically simplify the ease of backup and restore of
the 'system state' of the majority of users on the majority of distributions, because we'll basically be able
to clearly say that /var does not include any 'system state' information and only needs to be backed
up/restored according to the needs of the specific services that use it.

I love the idea of having var-less system backups again and rpm is the only tool I can think of on the
distributions I'm familiar with that is impeding this.

Richard Brown
Linux Distribution Engineer - Future Technology Team
Chairman - openSUSE
Phone +4991174053-361
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 mailing list