* On 2/22/23 16:07, Johannes Meixner wrote:
I am wondering why it seems on Tumbleweed "zypper dup" is told here to be the only right way to update something?
Shouldn't package management work same on Tumbleweed and openSUSE Leap and SLES and others so that the user can select an arbitrary package to be updated (when a package update is available) and then the package management would do "the right thing" to ensure that afterwards the system is again in an consistent state regarding package dependencies.
In general, yes. The situation is more complicated for Tumbleweed, though. While there are QA checks even for Tumbleweed, packages tend to be in a less polished state. Additionally, packages in Tumbleweed might get downgraded, which is unheard of in Leap (GA) and SLE (and if it does happen, it's still implemented as an upgrade by means of bumping the epoch, IIRC).
But because afterwards things did no longer work the root cause was likely inproperly defined package dependencies so it seems there is a bug of missing package dependencies.
This is also true and nobody did object. That's clearly a case of missing run-time dependencies. This said, getting run-time dependencies right/complete is an extremely difficult task and maintainers often get them wrong. Fortunately, the build environments are pretty good at scanning for run-time dependencies and automatically add them, but the capabilities are mostly limited to shared libraries. In the special case discussed here, dependencies on packages providing interpreted scripts were missing and that was obviously not caught at build time - either because the build does not need the packages in the first place (which is naturally different from normal usage) or because the dependency was transitive, i.e., pulled in by a different build dependency. Transitive dependencies are especially difficult to track. Image an explicit dependency graph such as: A -dep-> B -dep-> C In such a scenario, A only has an explicit run-time dependency on B, but now image that A also run-time depends upon C, so we'd really have a dep graph like this: A -dep-> B -dep-> C [implicit: A -dep-> C] Since B depends upon C, A will work just fine, but if B drops the dependency upon C in the future, A will very suddenly break and it's not immediately clear why. Because Leap and SLE GA are very conservative regarding package upgrades (which means that most packages are locked to a specific version and only bugs are fixed through backports, i.e., additional patching), such a breakage is unlikely to occur. Factory is way more dynamic and hence more prone to such breakage. The whole point of recommending zypper dup is not to discredit other means of updating software, but to recommend a rather safe way of upgrading the system. If dependencies are correctly recorded and you know which packages to upgrade, picking individual packages and letting the package manager work its magic would certainly be an equivalent upgrade way. Edge cases like package downgrades and dependency bugs break this assumption, though. The other point is that users might have (a lot more) packages installed that won't be mentioned in the automatic mails sent to the list, which means that they will be using outdated and potentially insecure software without even realizing it if just cherry-picking packages. Mihai