Better handling of upgrade abortions due to inconsistency

[fbruetting]

At updating, I more and more often get the error “some base packages would be replaced”. As far as I know, this is due to the fact that the build server has not completely iterated over everything, which is why package versions differ from those of the base image. This is not the nicest user experience, and the users then have to try updating several times, until a consistent state is encountered.

Wouldn’t it be a good idea to instead leave out parts of the updates, which already “progressed too far”? So for example, if the dnf package got bumped, but the base image doesn’t reflect that yet, rpm-ostree could run the update successfully with updating to the second most recent version of the dnf package. For small update deltas, this likely means to just leave the dnf package at the current version, but at least everything else could be updated.

Another solution might be to gate all updates until the build server ran through everything, so that consistency is ensured at all times. I assume that this is easier, but has the downside that security updates would be deferred.

Thoughts? 😊

[jlebon]

Hmm, we should probably keep discussions about this in #415. We're definitely aware of the painful UX (a lot of {Fedora,Red Hat} CoreOS and Workstaion WG developers at this point run Silverblue :) ) and there's people like @owtaylor who are looking at ways to address this properly in Fedora.

Gonna close this one if you don't mind.
(Feel free to repost your comment over there though!)