Open kelvinfan001 opened 3 years ago
There's a prior issue on this too. I'm uncertain about doing this by default. In some cases it's desirable, in others maybe not. Hence (also out of conservatism) it probably needs to be opt-in, something like rpm-ostree deploy --lock-wait ...
(factor out --lock-wait
as a common option across a bunch of our CLI commands) etc.
I would wait by default when run non-interactively so scripts don't end up fragile for want of a flag. It just feels bad for something to be scriptable, successfully runnable (because there's no transaction active while testing) and then break in the field.
Alternatively, warn if (1) running non-interactively and (2) there isn't an explicit flag for wait/don't wait set. That would at least avoid the "failure in the field" risk of quietly not queuing.
It would be helpful to queue additional transactions when an ongoing transaction is being handled. This is useful for when the caller doesn't want to cancel the ongoing transaction, but also doesn't want to keep querying on whether the current transaction is finished before invoking a new transaction. For example, for Zincati's use case, Zincati currently attempts to register as the update driver during intialization, but simply gives up and skips this step if an error happens (such as another transaction in progress). The ability for rpm-ostree to queue up transactions would be convenient so Zincati wouldn't need to keep retrying at an arbitrary interval.