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.
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
