On Wed, Jan 12, 2022 at 2:04 AM Panu Matilainen <pmatilai(a)redhat.com> wrote:
On 1/12/22 10:45, Chris Murphy wrote:
> On Tue, Jan 11, 2022 at 2:00 AM Panu Matilainen <pmatilai(a)redhat.com> 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
> Either top-level directories have their own databases, so rpm
> 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
> /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. 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.