On Tue 2019-03-12 15:01:26 +0000, Simon McVittie wrote: > If I understand their position correctly, the Debian systemd maintainers > would consider that to be a misconfiguration, because > Depends: libpam-systemd is the official way for a package to say "I need > a fully working systemd-logind and systemd --user", and packages like > dbus-user-session are allowed to assume that. If a sysadmin wants to > not use pam_systemd (which will mean their systemd-logind doesn't work > correctly and systemd --user doesn't get started), they should remove > that package so it doesn't satisfy dependencies.
thanks for this clarification, it sounds reasonable to me. > I'd be very tempted to make dbus-user-session the only implementation of > dbus-session-bus on Linux if it wasn't for the systemd-related political > reasons not to, because it's becoming increasingly clear to me that the > "one bus per X11 display" case is decreasing in viability over time > as upstreams and packagers both start to assume (the equivalent of) > dbus-user-session. This makes me a little bit sad, as someone who has in the past made good use of multiple X11 displays for the same user, but i agree that it reflects current reality pretty clearly. Furthermore, the main use cases i had in the past for multiple X11 displays were (a) testing, and (b) X11 isolation, both of which are better served by a distinct user account in the first place. > No, I don't think we should. Many packages explicitly use dbus-launch > (which is in dbus-x11.deb), even packages that should really be using > something else (see my 2016 MBF). Historical design choices in dbus-launch > mean that it does two different things when run with different options: > some options try to reuse an existing bus, but some options guarantee > to start a new bus. fwiw, i helped someone debug a problem on IRC the other day, and it was due to unnecessary use of dbus-launch in their ~/.Xsession (they were doing something like "exec dbus-launch awesome" instead of just "exec awesome", even though they had dbus-user-session installed). So the existence of dbus-launch on their system was actually causing them problems. I think this was a case of problem-solving via "don't do that then", but it seems likely that many folks have cargo-culted dbus-launch into places where they don't necessarily need it, and where it was unable to fall back to the dbus per-user session. thanks for all of your work in fixing as many of these corner cases as you've done, it's much appreciated! --dkg
signature.asc
Description: PGP signature
