On Fri, Jan 21, 2022 at 3:54 PM Adam Williamson
<adamwill(a)fedoraproject.org> wrote:
The release criteria aren't design documents. We're not defining the
intended behavior, exactly; we're defining a certain subset of known
expected behavior which we require to *work*.
The situations you describe are, essentially, "disaster recovery"
scenarios. What our current package managers do in this scenario is
"leave things in a corrupted state".
Yep. The (outdated, being updated) Workstation product requirements
doc says "Upgrade should be a safe process that never leaves the
system needing manual intervention." And that's not the case if
there's a crash or power failure. It's definitely manual intervention
time to recover.
But how could Fedora QA enforce what amounts to an aspirational
requirement? I think it's a good aspiration and should be in the next
revision, but also needs recommitting to it.
That's been the case for years and
will likely continue to be so.
I hope it won't continue much longer. On the one hand rpm-ostree is
pretty much there, and on the other hand btrfs can make it trivially
cheap to apply updates/upgrades on snapshots *instead* of the current
running system. A crash or powerfail with either transactional model
means you're booting the current unmodified root. So there is a way
forward.
So, I'd say there isn't really anything useful we could do by
writing
criteria around the scenario of interrupted updates.
I think there's a "plug in your laptop" requirement by GNOME Software.
If for some reason that check, and inhibitor, weren't working, i.e. a
regression, I think it could be considered a blocker. It'd be a
manifestly bad idea to let a laptop start doing an major version
upgrade without power. If the system shuts down during package
installation, manual intervention would be required to recover.
It's worth noting that we do have one rpm-ostree based
release-blocking
edition at present - IoT - and we may have more (e.g. Silverblue and/or
CoreOS) in future. For rpm-ostree based installs, we can and do assert
in the release criteria that rollbacks and rebases work, for recovery
from broken update attempts:
Yep, good
https://fedoraproject.org/wiki/Basic_Release_Criteria#rpm-ostree_requirem...
because that is how things are designed to work, and it's clearly
important enough that we should make it part of the release criteria
that things actually work that way. But for traditional RPM-based
installs, it doesn't really seem like something we can usefully address
in the criteria to me.
Not yet.
--
Chris Murphy