On 1/12/22 10:45, Chris Murphy wrote:
On Tue, Jan 11, 2022 at 2:00 AM Panu Matilainen <pmatilai@xxxxxxxxxx> wrote:
The problem with /usr/something is that the rpmdb is not specific to
/usr contents at all, and unlike any other content in there, so putting
it there just *feels so wrong*. That's what /state or /sysimage or, as
we now have, /var supposedly solves.
I thought I'd suggested something at / level back then (in
https://lists.rpm.org/pipermail/rpm-maint/2017-October/006697.html
and/or
https://lists.rpm.org/pipermail/rpm-maint/2017-October/006699.html) but
seems like memory is failing me :) Maybe I thought it would seem too
outrageous to FHS believers to bother.
The point was though, that the rpmdb is not at all the only data of this
kind and so having a dedicated home makes sense.
For many practical purposes it's probably just rearranging the chairs,
but a separate top-level directory describing the *system* state seems
instinctively *much* more correct solution to it than stuffing it
somewhere deep inside a loosely related fs.
If rpm is constrained to /usr, then its database can properly be
somewhere in /usr
If rpm is unconstrained, with transactions touching any of /usr /var
/opt /etc, the resulting paradigm is inherently complicated, and an
additional top-level directory doesn't help make it less complicated.
WTF is this talk about constraining? There's no such constraint in rpm,
and never will. And Fedora packages are not constrained there either, a
vast percentage places stuff in /etc, touches directory tree in /var and
then there's /boot and the software collections and third party software.
Either top-level directories have their own databases, so rpm knows
what's in them even if one is rolled back but not another; or there's
one database to describe all of these top-level directories which then
need to share a single (sub)volume so they're all snapshot and rolled
back together. Either way, there's additionally a need for carve outs
for things that shouldn't be rolled back.
Erm. Packages don't live conveniently inside a single top level tree,
they can't be split up that way. Many if not most span at least /etc and
/usr, and /usr may be further split into separate mounts (eg /usr/local
or /usr/share). And many things which install to /opt also place things
into /usr for desktop integration.
We have an example of the latter. (open)SUSE's current layout. There's
a 10 line /etc/fstab, 9 of which are various Btrfs subvolumes to
achieve the necessary carve out. It's sufficiently complex that the
direction they're looking to go in is one in which rpm's only touch
/usr. There's /usr/etc for read-only systemd defaults. And local
customizations go in /etc. Much like rpm-ostree.
Projects within two rpm-based distros independently came to realize
that unconstrained rpm is difficult. Where rpm-ostree decided to do
the hard work of actually becoming aware of the reality there's
multiple system roots.
I don't understand the question. Rpm tracks and cares about all content
it knows about equally, regardless of the path. /usr is NOT special in
any way to rpm, it's just that most of *distro* content ends up in there
but a huge number of packages have content spread across /etc too.
I think rpm can't remain
static for all time. It either needs to become aware of multiple root
trees, and even mix and match top-level directories to create variable
roots. And possibly even manage these things. Or it needs to constrain
its reach to /usr and /opt. Whether /usr and /opt are tied together,
or can be mix and match with their own rpmdb's, I have no strong
opinion on.
Oh, multiple rpmdbs. It's a while since that last turned up. It gets
tossed around as a solution but to me it looks like it brings more
problems than it solves.
Given the choice, I prefer rpm only touches /usr, which includes
/usr/var and /usr/etc.
But if left unconstrained, having databases inside the directories
they describe is more reliable than treating the database as a sidecar
file that can much more easily become disconnected with one or more
top-level directories it ostensibly describes the contents of.
Here seems to be another SMALL undocumented dependency of this change:
completing the /usrmove thing to cover the whole world including /opt,
/etc, /var, and presumably /boot as well because packages put stuff in it.
Rpm wont care if you want to move content from /etc to /usr/etc and
ditto for /var, /opt and /boot which is also used by packages, ie to
complete to complete the great /usrmove thing started a decade ago. But
that's quite a hidden agenda in this change if you ask me.
- Panu -
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
