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. -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net _______________________________________________ test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to test-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/test@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
