Re: New top-level dir: /state [WAS: Re: F36 Change: Relocate RPM database to /usr (System-Wide Change] proposal)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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.

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.


-- 
Chris Murphy
_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux