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

[Neal Gompa]

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!