Maybe I should go into more detail of why I consider it so much of a problem: At the core of Tumbleweed we always do distribution upgrades. This means we always do the same thing as what is being done if one would upgrade from Leap 14 to Leap 15 or from Leap 15.5 to Leap 15.6 and the like. The only real difference is that in our case the changes between dist-upgrades are considerably smaller since a lot of people do these on a daily basis. Some do it rarer (e.g. because they only use the device once a week). That means that unlike in between version jumps of regular release distros, we introduce even service changes quite a bit more often. Because of that we somehow need to make sure that the system works. Let's just imagine that at some point somebody comes around and creates a successor for DBus for whatever reason and systemd decides that they want to switch to it long term and after a few years of supporting both they drop the old. That means that at the point the old would be dropped, everybody's system, where it didn't work correctly or only half (in my case one of these two services were enabled and the other disabled), would suddenly break on a fundamental basis. Requiring people to look at a mailing list for that or do clean reinstalls is not a solution to this, it's a stop gap. 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. 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. 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). Am 29.06.23 um 00:21 schrieb Kilian Hanich:
Am 28.06.23 um 21:41 schrieb Andrei Borzenkov:
Although we could deal with this (and possible future accidents) via systemd.preset and calling systemctl preset $UNIT in the scriplets.
Which is no solution because it ignores decision of local administrator.
From the systemd.preset manpage:
systemctl preset is used by the post install scriptlets of rpm packages (or other OS package formats), to enable/disable specific units by default on package installation, enforcing distribution, spin or administrator preset policy.
Administrators can overwrite distro policy by providing a preset file of higher priority.
Additionally it would still be off if the administrator masked the service.
-- Sincerely
Kilian Hanich
-- Sincerely Kilian Hanich