Summary: | [PATCH] add /lib/dbus-1/system-services to the search path for services | ||
---|---|---|---|
Product: | dbus | Reporter: | Lennart Poettering <lennart> |
Component: | core | Assignee: | Havoc Pennington <hp> |
Status: | RESOLVED FIXED | QA Contact: | John (J5) Palmieri <johnp> |
Severity: | normal | ||
Priority: | medium | CC: | walters |
Version: | 1.4.x | Keywords: | patch |
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | review- | ||
i915 platform: | i915 features: | ||
Bug Depends on: | |||
Bug Blocks: | 35306, 36074 | ||
Attachments: |
the patch
second version of the patch |
Description
Lennart Poettering
2011-03-11 13:52:57 UTC
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.