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

Neal Gompa ngompa13 at gmail.com
Mon Oct 16 19:52:42 UTC 2017

On Mon, Oct 16, 2017 at 11:22 AM, Richard Brown <rbrown at suse.de> wrote:
> 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.
> https://build.opensuse.org/package/rdiff/Base:System/rpm?linkrev=base&rev=404
> 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.

In RPM-based distributions, sure. But all Linux distributions "suffer"
from this because they *all* put their package management database (or
equivalent) in /var/lib. Honestly, if /usr/com was still a thing, it'd
probably be the right place to put it. But that hasn't been part of
the file tree since before Linux...

真実はいつも一つ!/ Always, there's only one truth!

More information about the Rpm-maint mailing list