Sorry for the long delay to this response; it got pre-empted by something more urgent, and then I forgot about it.
On Sun, 18 Sep 2016 at 22:19:38 +0900, Osamu Aoki wrote: > So listing im-config in MBF seems to be FALSE POSITIVE if it is only > based on this string in the comment. Yes, looks like a false positive. My dd-list was based on a simple search for dbus-(x11|launch) on codesearch.debian.net. I didn't analyze its results in detail before announcing the MBF, because by the time I'd gone to the effort of inspecting each potentially-affected package, I had all the necessary information to file a bug with concrete recommendations for that package. The MBF is now complete (I think) and im-config didn't receive a bug. However, im-config is the sort of thing that might need adjustment to work as intended with systemd user services. That's really outside the scope of this MBF, but it's in the same sort of space. > I have "The hook script for dbus-launch is in 75 which changes $STARTUP > string." in the comment of im-config. The current dbus-launch in 75 > does not touch $STARTUP any more. This change seems to break how > im-config uses $STARTUP. The root problem here is that /etc/X11/Xsession.d does two orthogonal things: it sets environment variables, and it also starts services like dbus-daemon (and whatever input method is started by im-launch?), some of which might themselves need environment variables (leading to circular dependencies if we're not careful). Increasingly, upstream software is solving this by using a real service manager (systemd --user, aka user@${UID}.service) instead of a directory full of shell scripts: if Xsession.d is like a per-user version of /etc/init.d, then systemd --user is like a per-user version of the pid 1 instance of systemd. dbus-user-session is the equivalent of dbus-x11 for the systemd --user service manager. Another popular option is to use freedesktop.org autostarting (/etc/xdg/autostart/*.desktop), and rely on a freedesktop.org session manager like gnome-session to read that directory. What does im-launch do? Does it spawn subprocesses that are input methods? If so, what environment variables (if any) do they need set in their environment? Does im-launch set environment variables? Can the values of those environment variables be hard-coded in a script or based on simple substitutions (like dbus-user-session's DBUS_SESSION_BUS_ADDRESS=unix:path=$XDG_RUNTIME_DIR/bus) or are they variable and hard to determine until services start (like dbus-x11's DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-5298fc9w or whatever other socket name tempnam() chooses)? For your reference, here is how the startup chain worked in jessie (assuming GNOME just to have a concrete example, but gnome-session could be replaced with any other desktop environment, window manager or similar): * 20dbus_xdg-runtime is absent * At sequence number 50 or thereabouts, $STARTUP is something like "gnome-session" * 70im-config_launch sets a bunch of environment variables and changes $STARTUP to "/usr/bin/im-launch gnome-session" * 75dbus_dbus-launch changes $STARTUP from e.g. "gnome-session" to "dbus-launch --exit-with-session /usr/bin/im-launch gnome-session" * 99x11-common_start execs $STARTUP Here is how it will work in stretch with dbus-x11 but without dbus-user-session: * 20dbus_xdg-runtime is absent * At sequence number 50, $STARTUP is something like "gnome-session" * 70im-config_launch sets a bunch of environment variables and changes $STARTUP to "/usr/bin/im-launch gnome-session" * 75dbus_dbus-launch starts dbus-launch and dbus-daemon * 95dbus_update-activation-env takes any environment variables that were set between 75dbus_dbus-launch and here, and sends them to the dbus-daemon via a D-Bus method call, so that D-Bus session services will also get those variables set (unless they were started already) * 99x11-common_start execs $STARTUP, as before and in stretch with dbus-user-session: * libpam-systemd tells systemd-logind that a login session was started, and systemd-logind tells pid 1 to start the system service user@$UID.service, i.e. systemd --user, which in turn starts the user services dbus.socket and dbus.service, i.e. dbus-daemon --session * 20dbus_xdg-runtime puts DBUS_SESSION_BUS_ADDRESS=unix:path=$XDG_RUNTIME_DIR/bus in the environment * At sequence number 50, $STARTUP is something like "gnome-session" * 70im-config_launch sets a bunch of environment variables and changes $STARTUP to "/usr/bin/im-launch gnome-session" * If dbus-x11 is installed, 75dbus_dbus-launch sees that DBUS_SESSION_BUS_ADDRESS is already installed and does nothing * If dbus-x11 is installed, 95dbus_update-activation-env takes any environment variables that were set before this point, and sends them to the dbus-daemon and to systemd --user via a D-Bus method call, so that D-Bus session services and systemd user services will also get those variables set (unless they were started already) * 99x11-common_start execs $STARTUP, as before Regards, S