I'm sure an actual OpenSUSE expert can correct me, but there is some "dependency SAT solver" that SUSE has that resolves software versions. Sometimes it can't figure out what to do, so it'll spit out some prompt during upgrade that can be a bit difficult to decipher (e.g. keep an obsolete dependency, uninstall the thing requiring it, etc). Sometimes I would choose the wrong thing and break something that was relying on some behavior, but not captured by zypper/yum (e.g. a cmake project relying on specific behavior of some native library). Ultimately, that was my fault for being lazy in the "untracked external dependency" department, and it's easy to roll back with snapper.
> I'm sure an actual OpenSUSE expert can correct me, but there is some "dependency SAT solver" that SUSE has that resolves software versions. Sometimes it can't figure out what to do, so it'll spit out some prompt during upgrade that can be a bit difficult to decipher (e.g. keep an obsolete dependency, uninstall the thing requiring it, etc).
I'm not sure how all of this really shakes out formally, but one of the cool things about using a SAT solver for dependency resolution is that it is guaranteed to be complete: if a solution exists to the dependency resolution problem presented by your package management operation, zypper/libsolv is guaranteed to find it.
But sometimes, a weird thing may happen, and no such solution will exist. In a case like that, the best zypper can do is offer to amend your request in various (hopefully) minimal ways, and ask if you agree that any of those outcomes are 'good enough'. IME, zypper is pretty good at this. But unfortunately, answering those questions may require you to have a clearer picture of your system's state and your goals than many users/administrators do.
The safest thing to do when presented with those prompts is, of course, to abort. But snapper definitely makes messing around and trying your options less punishing than it might be!
