On Tue, 2021-03-30 at 19:35 +0000, Zbigniew Jędrzejewski-Szmek wrote: > On Tue, Mar 30, 2021 at 06:54:25PM +0000, Gary Buhrmaster wrote: > > On Tue, Mar 30, 2021 at 6:18 PM Zbigniew Jędrzejewski-Szmek > > <zbyszek@xxxxxxxxx> wrote: > > > > > There is no good way to do this. > > > > This is one of those cases where I occasionally > > miss a mainframe fix update feature to prevent > > certain bad automated results. > > > > In SMP/E, there was the concept of HOLD's for > > a fix. There were a number of HOLD reasons, > > but one was ACTION, which prevented the > > application of the fix unless the HOLD was > > released. I.e. you had to read the docs and > > either do, or prepare to do, whatever the > > ACTION said to do before you could proceed > > FWIW, with Debian's apt, that's more or less what you get: the > upgrade > will block and ask questions. I remember quite a few times I got burned by this behavior on Debian based systems - nothing better than to start a big system update and go away only to come back hours later and find it stuck at the ~10th package asking some useless question and not progressing with the update at all. Also given that package update transactions are not always atomic and can easily result in a broken system if interrupted in the middle, this also makes breakage more likely as the transaction remains in vulnerable state much longer than it would be otherwise necessary, waiting for the user to notice and answer the question. > We have never done this in the rpm world, > and while sometimes this makes things harder, I think this is the > right > choice in the long run. Essentially, interactive questions during > upgrades > are are fine as long as you have one or two or three servers per > human, > *and* the human has time and knowledge and energy to deal with the > questions. > But the world has changed, and we have many more machines per person, > and > many more non-power users then ever. > > Zbyszek > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
