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 apackage 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:
- * 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).
- * 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 -- 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
