On Thu, Jun 29, Kilian Hanich wrote:
So Let's actually look at what goes wrong here:
Currently we rely on the order zypper upgrades the packages, which is not deterministic for (in zypper's eyes) unrelated packages. That's prone to break. And quite frankly, I don't think that this is even a bug on any packages side, but a bug in the way we try to maintain this distribution. There isn't a fix we can apply to a package for that, that's not possible. We can only apply a fix to the policy we have here.
No, this is not the case. We don't rely on the order zypper upgrades the packages. We have a package with some configuration files and scripts, which normally makes sure, that services are enabled if they should be, independent of the order in which zypper upgrades the packages. Somebody broke this script one year ago, so that it does not work anymore at all. That's bad, and even worse it, that either nobody noticed this, or nobody cared to report it as bug. That the services get enabled in some cases depending on the order in which zypper upgrades the packages is only by accident, not design, as we run now in another case in which other scripts still work. The big problem is: It's not only wtmpdb, but __ALL__ services added to the preset list during the last 12 month are most likely broken! And it's not that something is just not installed or so, but the result is a broken system, something, which happens from time to time with Tumbleweed, even if we have all the testing before we release a snapshot. But this testing cannot test every case.
While you can maybe make the argument that this is just how it is and all Tumbleweed users need to follow news, make sure everything is fine and goes correctly and the like, other openSUSE distros like microOS and the like are intended to be fully automated in this aspect. They are explicitly intended that you don't need to do that.
Correct, and every month again a bug slips through testing and get's released to the users. We had already more than once that users need to do a rollback manually of MicroOS to recover from this. We don't have the perfect 100% QA, and as result, bugs happen. That's unavoidable.
We are in a pretty interesting situation here because Arch just goes and pretty much says "you are in charge of enabling/disabling basically everything, we don't do anything like that" (that's also why some call it a DIY distro and they only provide a "disable *" preset file). Debian has it's deb-systemd-helper to deal with this stuff (it keeps track of enabled/disabled and can figure out if it was enabled/disabled by admin or not if the admin doesn't mess with it).
And we have systemd-preset-common-SUSE to do that, like Debian has deb-systemd-helper. And if Debians deb-systemd-helper gets broken, the result is the same as now, where systemd-preset-common-SUSE was broken for far too long. But you can complain as long and loud as you want: as long as nobody has an idea, how to identify all the "broken" services from the last 12 month and fix them, without breaking the system by accident (so make it worse then the current situation), we cannot "fix" it with an update. Thorsten -- Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, Germany Managing Director: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien Moerman (HRB 36809, AG Nürnberg)