Hi, Thanks for the question, sorry I missed this in my last email. On 7/5/22 22:45, Larry Len Rainey wrote:

Almost everything I have written for OpenSUSE uses dbus-launch which is in dbus-1 - is that affected too?

According to # cnf dbus-launch                               Program 'dbus-launch' is present in package 'dbus-1', which is installed on your system.

Absolute path to 'dbus-launch' is '/usr/bin/dbus-launch'. Please check your $PATH variable to see whether it contains the mentioned path.

There are two scenarios with this, firstly there are some cases where dbus-launch is no longer needed, these are if you are using the system bus or your user is graphically logged in, for both these cases dbus-daemon and dbus-broker are socket activated via systemd. Continuing to call dbus-launch in these cases has the potential to break things in the short term as whatever you launch with dbus-launch will try and use dbus-daemon and wont be able to talk to everything else using dbus-broker. In these cases you could swap to using dbus-broker-launch but this shouldn't be necessary. There are other cases where a systmed session is not launched such as logging in via ssh (maybe as a distro we should be changing this but that is another question). Another case is if you are running certain services as a specific user and want a separate dbus session for them. In these cases it should be possible to keep calling dbus-launch, although switichg to dbus-broker-launch will be more correct. THis should continue to work as during the migration period they will just continue using dbus-daemon while everything else uses dbus-broker. When I remove the dbus-daemon package i'll add a compatibility symlink from dbus-launch to dbus-broker-launch but I can't do that while the two packages are co installable.

On 7/5/22 07:06, Simon Lees wrote:

...

Hi All,

For Tumbleweed and ALP we plan to follow Red Hat / Fedora / Debian and move from dbus-daemon to dbus-broker as it has a number of advantages and is what upstream is now focusing on.

While one of the goals here is to provide the same user experience there will be a couple of changes that will likely require adjustments in a few packages.

1. tools such as dbus-send and dbus-uuid will no longer be installed by default on all systems (we have many use cases that will simply no longer need them and this follows other distro's). Currently the package dbus-1-tools exists and is required by dbus-1 but that will change maybe to a recommends so if you know your package needs one of these tools you can add the Requires there now, otherwise I plan to go through and look at debian and fedora to try and find any packages that need this requires before it becomes optional for dbus.

2. The symlink from /etc/machine-id to /var/lib/dbus/machine-id will no longer be present on all machines and software should be adapted to use /etc/machine-id from systemd rather then the dbus copy. Again this has already happened for Debian and Fedora so hopefully many upstreams have already adapted to this.

I'll outline the plan / timeline below.

1. Currently - dbus-broker has been in the distro for quite some time and the dbus-1 package has already been split up and we are at the point of asking people nicely to start testing (instructions below), myself and at least several other people have already been testing this without issues.

2. In 2-3 weeks if I don't hear of any issues we will update the systemd presets to enable dbus-broker rather then dbus-daemon.

3. Unless someone indicates they really want to keep maintaining dbus-daemon and have good reasons for doing so I will make dbus-daemon uninstallable.

4. Once we have done the work to ensure that as many packages that use dbus-send and other tools require the tools package we will drop the requires for dbus-tools from the dbus package. Instead it will probably move to being a Recommends in one of the patterns so it still ends up on most users machines.

Switching to dbus-broker: Run the following as root zypper in dbus-broker systemctl disable dbus systemctl enable dbus-broker systemctl --global disable dbus systemctl --global enable dbus-broker

https://www.mail-archive.com/debian-policy@lists.debian.org/msg35437.html https://fedoraproject.org/wiki/Changes/DbusBrokerAsTheDefaultDbusImplementat...

-- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

On 7/9/22 15:54, David C. Rankin wrote:

On 7/5/22 07:06, Simon Lees wrote:

...

Hi All,

For Tumbleweed and ALP we plan to follow Red Hat / Fedora / Debian and move from dbus-daemon to dbus-broker as it has a number of advantages and is what upstream is now focusing on.

Simon,

  When you say "is what upstream is now focusing on" -- who/what is upstream? dbus-broker and dbus are separate (e.g. https://github.com/bus1/dbus-broker), but can be used as a replacement. Seeing the upstream comment, I went and checked what Arch is doing (as they drop anything not maintained upstream), and Arch is using dbus-daemon. Or did you mean Tumbleweed and ALP as upstream??

While they are separate projects the developers who were contributing the most into the dbus-daemon upstream in the last few years are now focusing more on dbus-broker. At this stage the developers of dbus-daemon have stated that they don't plan to stop maintaining it (ie fixing security issues and bugs) but at the same time they don't plan to add any new features or do any significant development on it.

  Also what are the advantages of making the change to dbus-broker? What are we gaining by doing this?

The largest one is performance, under certain use cases with high traffic volumes dbus-daemon is unable to keep up and starts dropping messages which isn't ideal. When the dbus spec was originally created there were a bunch of extra features that people thought they'd use but didn't ever use including things like remote connections and many other deprecated features. Due to the design of dbus-daemon some of the issues that lead to poor performance weren't easily fixable so by focusing on performance, the use cases that people most use and by allowing themselves to use Linux only api's the dbus-broker rewrite is able to address these issues while maintaining compatibility with the current version of the spec. You can read https://dvdhrm.github.io/rethinking-the-dbus-message-bus/ for a more detailed description. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

On 9/21/23 04:19, Simon Lees wrote:

On 7/5/22 21:36, Simon Lees wrote:

...

Hi All,

For Tumbleweed and ALP we plan to follow Red Hat / Fedora / Debian and move from dbus-daemon to dbus-broker as it has a number of advantages and is what upstream is now focusing on.

While one of the goals here is to provide the same user experience there will be a couple of changes that will likely require adjustments in a few packages.

1. tools such as dbus-send and dbus-uuid will no longer be installed by default on all systems (we have many use cases that will simply no longer need them and this follows other distro's). Currently the package dbus-1-tools exists and is required by dbus-1 but that will change maybe to a recommends so if you know your package needs one of these tools you can add the Requires there now, otherwise I plan to go through and look at debian and fedora to try and find any packages that need this requires before it becomes optional for dbus.

2. The symlink from /etc/machine-id to /var/lib/dbus/machine-id will no longer be present on all machines and software should be adapted to use /etc/machine-id from systemd rather then the dbus copy. Again this has already happened for Debian and Fedora so hopefully many upstreams have already adapted to this.

I'll outline the plan / timeline below.

1. Currently - dbus-broker has been in the distro for quite some time and the dbus-1 package has already been split up and we are at the point of asking people nicely to start testing (instructions below), myself and at least several other people have already been testing this without issues.

2. In 2-3 weeks if I don't hear of any issues we will update the systemd presets to enable dbus-broker rather then dbus-daemon.

3. Unless someone indicates they really want to keep maintaining dbus-daemon and have good reasons for doing so I will make dbus-daemon uninstallable.

Well after a really long 2-3 weeks of over a year, this change will probably land in tumbleweed in the next couple of days. The other change to note is dbus-run-session may no longer be present on all systems although gdm has an explicit requires for it so it may not be obvious at first.

Hi Simon, I just upedated to 20231001 and dbus-daemon is still installed and dbus-broker is NOT installed. Was this delayed or do we need to making make the switch ? -- Regards, Joe