[Rpm-maint] RFC: Relocate RPM and DNF databases to /usr

[Colin Walters]

On Wed, Dec 15, 2021, at 5:34 PM, Florian Weimer wrote:
> * Chris Murphy:
>
>> Fedora 36 seems like a good time to do this. What do you think?
>
> It's a bit odd to locate a database under /usr that isn't pre-built and
> installed.  

Why is that odd?  

> I guess in theory there could be systems with a read-only
> /usr out there that still allow installation of packages into /opt.
>
> Does it really help to improve the snapshot situation? 

Yes.  

I didn't wake up one day and say "hey you know what, today I'm going to move the rpm database just for fun".  Neither, for that matter did the OpenSUSE folks.  We haven't had this conversation over and over throughout the years just because it was some minor thing.

What I *did* wake up one day and say I'm going to do is make upgrades transactional and offline by default and hence safe.  No one should ever fear starting an operating system upgrade while their laptop is at 30% battery.  Administrators running important servers must be able to easily roll back when the kernel *or* systemd (or something) else regresses, because it's software, it regresses all the time despite our best efforts.

So yes again, this does matter.  And it matters because whether you're doing "image based upgrades" like ostree or just "client side offline updates" like the https://kubic.opensuse.org/documentation/man-pages/transactional-update.8.html thing - it's very important *what data specifically* is versioned/snapshotted and what isn't.  On an ostree system for example, it's completely normal that there are *two* rpm databases (one you're running, one that's pending in the new root).  

All the data in the rpmdb is about content that's in `/usr`.


> What about
> software under /opt? 

https://github.com/coreos/rpm-ostree/issues/233
Today indeed, rpm-ostree explicitly denies that.  Which, note we can do because we basically take over chunks of what librpm is doing on non-ostree systems.  But, it would be nice to drive some of this support into librpm too so it applies to non-ostree-but-snapshottable systems.


>  Maybe this needs multiple RPM databases
> eventually, roughly aligned along file system boundaries.

Yeah, that's one approach, though I would scope it really to just "/usr rpmdb" and "/usr/local" rpmdb - i.e. `/opt` and `/usr/local` are basically the same thing with different names.