:: [devuan-dev] bug#745: dbus-x11: Sev…
Pàgina inicial
Delete this message
Reply to this message
Autor: Simon McVittie
Data:  
A: Mark Hindley
CC: Martin Steigerwald, 745, 1032368
Assumpte: [devuan-dev] bug#745: dbus-x11: Several processes in Plasma session including krunner have / as current working directory
Control: forwarded -1 https://gitlab.freedesktop.org/dbus/dbus/-/issues/214

On Mon, 06 Mar 2023 at 11:52:08 +0000, Mark Hindley wrote:
> Simon, might the implications of that be reviewed again upstream? I
> found an upstream issue with patch to implement such behaviour that has not been
> merged <https://gitlab.freedesktop.org/dbus/dbus/-/issues/214>.


I had completely forgotten about that issue report. At least I'm
consistent: 4 years ago, I also said something along the lines of "maybe,
but I'm concerned that this is going to break someone's workflow". If
there is consensus even among the users of highly change-averse
distributions that $HOME is a better working directory than /, then maybe
this can/should change in the dbus 1.15.x and Debian-13-as-testing cycle.

As you said, during the Debian 12 freeze is not the time to change this.
dbus 1.16.0 would be the earliest stable release of dbus that is likely
to have this behaviour change upstream, although obviously Devuan is
already patching the dbus package and is free to backport whatever
changes they are willing to take responsibility for.

What I absolutely don't want is to make the change, and then 2 years
later get hate mail from someone telling me that I've broken their
system by making dbus-launch prevent /home from being unmounted and
"why can't you just" add an option to use daemon(3).

Because the recommended and most-common way to run the session bus in
2023 is via the dbus.service managed by `systemd --user` (that's the
dbus-user-session package in Debian), it is primarily users of more
traditional system configurations (sysv-rc or similar, X11, dbus-x11,
dbus-launch) that will be affected by this. I do not have enough time
available for dbus to carry out testing on arbitrary OS configurations,
and I am not able to take responsibility for researching whether this
will break anyone's use-case. It's up to the people who maintain those
more traditional system configurations to tell me whether dbus/dbus#214
is what you want or not.

Because dbus-launch is already poorly-understood spaghetti code, I
specifically don't want this to be a configuration option: it should
either always use $HOME as in David King's proposed patch, or always use
"/" as it does in 1.14.x. Having two rarely-tested code paths is worse
than having one.

    smcv