Created attachment 44367 [details] [review] the patch In order to allow D-Bus usage during early boot (where /usr is not accessible) also search for bus activation files in /lib/dbus-1/system-services/. This is only a first step in the right direction, before we really can boot without /usr we'd need to move all current activation files (or possibly replace /usr/dbus-1/system-services to a symlink to /lib/dbus-1/system-services).
Hmm; they aren't really architecture-dependent. I don't have a better idea though (/etc seems out, right?). We should probably explicitly document that the location of system services is *always* /lib/dbus-1, it specifically does *not* vary even in multilib operating systems.
(In reply to comment #1) > Hmm; they aren't really architecture-dependent. I don't have a better idea > though (/etc seems out, right?). "share" translates to "lib" in the root directory. A big chunk of programs handle it that way and so should we. For example, udev stores its rules in /lib/udev/rules.d, systemd its unit files in /lib/systemd/system/, ALSA its mixer init db in /lib/alsa/init/, kbd its data files in /lib/kbd/... and so on. > We should probably explicitly document that the location of system services is > *always* /lib/dbus-1, it specifically does *not* vary even in multilib > operating systems. Hmm, I don't think this is something to document in D-Bus much rather in the FHS if it ever comes back from the dead.
(In reply to comment #2) > (In reply to comment #1) > > Hmm; they aren't really architecture-dependent. I don't have a better idea > > though (/etc seems out, right?). > > "share" translates to "lib" in the root directory. A big chunk of programs > handle it that way and so should we. For example, udev stores its rules in > /lib/udev/rules.d, systemd its unit files in /lib/systemd/system/, ALSA its > mixer init db in /lib/alsa/init/, kbd its data files in /lib/kbd/... and so on. Yep, makes sense. > Hmm, I don't think this is something to document in D-Bus much rather in the > FHS if it ever comes back from the dead. Ok.
Review of attachment 44367 [details] [review]: If XDG_DATA_DIRS is set, it'll completely defeat this, which seems weird. I think it should be appended separately like ${datadir}/dbus-1 is, and the precedence order should go: XDG_DATA_DIRS/dbus-1 (default is {/usr/local/share,/usr/share}/dbus-1 as usual) ${datadir}/dbus-1 (usually also /usr/share/dbus-1 but might be /opt/MonolithicThing/share/dbus-1) /lib/dbus-1 (or maybe with /lib/dbus-1 before the ${datadir}).
(In reply to comment #1) > We should probably explicitly document that the location of system services is > *always* /lib/dbus-1, it specifically does *not* vary even in multilib > operating systems. I also think we should explicitly document this; this is "/lib as /usr/share replacement", not "/lib as arch-dep directory". In lib64-style systems it specifically isn't /lib64/dbus-1, and in Debian-style multiarch it isn't /lib/x86_64-linux-glibc/dbus-1 either. However, we don't currently document the location of system *or* session services in the Specification. I'll clone a bug.
I'd be OK with this going into 1.4 when ready.
Created attachment 49634 [details] [review] second version of the patch Here's an updated patch that adds /lib to the search path even if the XDG env var is set.
Review of attachment 49634 [details] [review]: Looks good, r+
Commited to master and dbus-1.4
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.