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

[Panu Matilainen]

On 10/16/2017 06:22 PM, Richard Brown 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?

Well you skipped my alternative suggestion entirely.

I don't see /usr/lib as a *good* place for this, but if a new top level 
directory in /usr seems too much then maybe /usr/lib/sysimage or such 
(and then rpm/rpmdb under that) would be a reasonable compromise. The 
point is, rpm is not the only thing with data like this so it'd make 
sense to have a common home for them all, instead of adding separate 
/usr/lib/foo directories for each.

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

By handling migration I meant rpm upstream code, not spec kludgery. 
Precisely because specs are distro-specific.

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

As Neal pointed out, there's dpkg and the other package management 
systems that put their stuff in /var too. And you don't need to go even 
outside the rpm land for those other things, there's yum/dnf/PackageKit 
(and who knows what else) that keep their own databases on 
install-related information in /var.

	- Panu -