On 2022-01-21 5:54 p.m., Adam Williamson wrote:
On Fri, 2022-01-21 at 14:20 -0500, John Mellor wrote:
I am unclear from this proposal on what is supposed to happen if a
package is not completely installed. E.g: a powerdown or other outage
causes the post-install script in an installed rpm to not be run. A few
packages like the kernel can take ten minutes to install properly, and
you may not have enough battery left to get that done when the power
goes out. The package and its dependencies are installed, but not
initialized correctly. Does it force an installer continuation or redo
at boot time for these partial installs, does in uninstall the app and
its whole chain of dependencies, or does it just leave things in a
corrupted state?
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". That's been the case for years and
will likely continue to be so. It seems kinda pointless to have a
release criterion asserting that this is the case, and we do not do
'enforced-product-design-by-release-criteria' (where we make up release
criteria that describe how we'd *like* things to behave, and then try
and use that as a stick to make the developers make things actually
behave that way).
So, I'd say there isn't really anything useful we could do by writing
criteria around the scenario of interrupted updates.
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:
https://fedoraproject.org/wiki/Basic_Release_Criteria#rpm-ostree_requirements
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.
Ok, so would that allowance not violate 2 of the proposed criteria:
1. * The displayed state of software or software sources must not
differ from their actual state. (E.g. an RPM package must not be
shown as installed when it is not, a repository must not be shown as
disabled or missing when it is enabled, etc).
2. * The package manager must never make the system enter an
inconsistent or unbootable state. (E.g. damage the local software
database, remove wrong system files, break the bootloader, etc).
Or is the purpose of this document just to provide validation criteria
for the existing installer behaviour?
--
John Mellor
_______________________________________________
test mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
