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]

 




Dne 12. 01. 22 v 22:05 Chris Murphy napsal(a):
On Wed, Jan 12, 2022 at 2:04 AM Panu Matilainen <pmatilai@xxxxxxxxxx> wrote:
On 1/12/22 10:45, Chris Murphy wrote:
On Tue, Jan 11, 2022 at 2:00 AM Panu Matilainen <pmatilai@xxxxxxxxxx> wrote:
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.
I'm not talking about changing the nature of the beast. I'm talking
about how it's used as a tool in a distribution with a lot of other
requirements and tradeoffs.

Expanding rpm is also a valid path. We have an example "DNF snapper
plug-in" that demonstrates at least DNF *could* get into the business
of managing snapshots and rollbacks, if it wants that responsibility,
if it's helpful and worth the effort, and if the resources exist to do
it. That's an interesting discussion.

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.
/boot might need its own manager(s). I'm strongly leaning toward
bootupd and fwupd being the only things that touch /boot and
everything else is proscribed.

/boot is a small but hot mess right now. RPM, grub, grubby, dracut,
all can touch /boot and in the Boot Loader Spec context there's
multiple OS's sharing /boot. About the only thing I like better is
linux as the bootloader, e.g. Linux Boot, so we have real device and
file system drivers. Anything that manages /boot needs to needs
understand snapshots, and which kernel+initramfs can boot which
snapshots.

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.
Right. I view this as a criticism, not a benefit though. Neither rpm
nor the FHS are organizing things in a way that helps us do rollbacks.
They're impediments we keep having to take other shortcuts and
workarounds to achieve that goal, and as yet they still have too many
shortcomings. It really isn't to be underestimated the importance of
multiple independent parties coming to the same kinds of conclusions.


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.
This change proposal is narrow in scope. It imagines a future
snapshot+rollback regime of some kind, but isn't depending on any
particular file system or way of achieving it.

I personally like the transactional updates approach. I like what
rpm-ostree is doing, updating the system root out of band rather than
updating the currently running system.


Actually, shouldn't rpm-ostree carry around some copy of the RPM database, which would describe the state of /usr and once the update is successful (or snapshot active?), merge it into the main system RPM database? Apparently, something like this is already happening e.g. for /etc content if I understand it correctly. Or this is the direction in which the /boot will be handled eventually. Or possibly it could be just some linked (possibly just read only) database.

IOW, imagine, that we still keep the system read/write RPM database in /var and we teach RPM to use additional database(s). So RPM would know that there might be some additional database e.g. in /usr/var/ ... The system database would not know nothing about content of /usr, but once /usr was mounted, `rpm -q` would provide the information from the linked RPM database.


Vít


  I like the idea these updates
can happen in a container, if they fail for any reason we just remove
that bad tree - it's a completely disposable thing until it
successfully updates and maybe we can even automate some simple tests
(it gets to X milestone in the boot process) before we activate it as
the current root. I like the idea of users being able to follow the
trail of breadcrumbs of how systems boot. My strong bias from many
years in Fedora QA is we deal every cycle with boot/startup failure in
some form or another, and the less obscure less fragile more
self-describing and standard that process can be, the easier it is to
avoid, find and fix problems.

We also know that (open)SUSE has proven a working boot to snapshot
design. It's just complicated. They're the first to admit it, and that
they've learned a lot from the experience. Things have changed in 10
years. I imagine we're wandering in a very big library and we don't
know exactly what book we're looking for, but we're perusing with a
purpose. If there is a hidden agenda, it's because none of the change
owners are attached to any one particular boot to snapshot design. We
know it's not going to look identical to anything else out there
because it has to work with a purpose for Fedora, but we also don't
know the details of what that's going to look like.



--
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

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

_______________________________________________
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