Discussion:
systemd build dependency on dbus
(too old to reply)
Filipe Brandenburger
2014-08-20 18:45:06 UTC
Permalink
Hi,

I'm wondering about systemd's build dependency on dbus... I see that
the configure script checks for dbus, but the exported variables are
rarely used.

For instance, HAVE_DBUS is defined but only used in test case test-bus-marshal.

None of the binaries (other than test case test-bus-marshal) are
linked against libdbus-1.so.

Is dbus really needed to build systemd?

Is this part of the transition from dbus to kdbus?

Thanks!
Filipe
Lennart Poettering
2014-08-20 22:27:21 UTC
Permalink
Post by Filipe Brandenburger
Hi,
I'm wondering about systemd's build dependency on dbus... I see that
the configure script checks for dbus, but the exported variables are
rarely used.
For instance, HAVE_DBUS is defined but only used in test case test-bus-marshal.
None of the binaries (other than test case test-bus-marshal) are
linked against libdbus-1.so.
Is dbus really needed to build systemd?
Is this part of the transition from dbus to kdbus?
Well, we have our own dbus library implementation since a while
("sd-bus") that supports both dbus1 and kdbus as transport. We only link
against libdbus1 in a test to validate our marshalling against the dbus1
one.

We need dbus1 at runtime though, unless you run kdbus. Hence we never
bothered to remove this dependency or make it optional. But we probably
should make it optional.

Lennart
--
Lennart Poettering, Red Hat
Filipe Brandenburger
2014-08-26 04:58:49 UTC
Permalink
On Wed, Aug 20, 2014 at 3:27 PM, Lennart Poettering
Post by Lennart Poettering
Well, we have our own dbus library implementation since a while
("sd-bus") that supports both dbus1 and kdbus as transport. We only link
against libdbus1 in a test to validate our marshalling against the dbus1
one.
That's interesting.

Indeed it would be good to clarify that libdbus is not required at
build time (except for the test case, and maybe it can be made
optional or dynamic loaded in that one?) There seems to be other
configurations that are pulled from dbus, like the dbuspolicydir,
dbussessionservicedir, etc.

I mean that because there are still many pages that list systemd and
dbus as a circular dependency, for example:
http://wiki.gentoo.org/wiki/Systemd#Installation

And it looks like that's no longer the case...

Cheers,
Filipe
Lennart Poettering
2014-10-22 18:07:56 UTC
Permalink
Post by Filipe Brandenburger
On Wed, Aug 20, 2014 at 3:27 PM, Lennart Poettering
Post by Lennart Poettering
Well, we have our own dbus library implementation since a while
("sd-bus") that supports both dbus1 and kdbus as transport. We only link
against libdbus1 in a test to validate our marshalling against the dbus1
one.
That's interesting.
Indeed it would be good to clarify that libdbus is not required at
build time (except for the test case, and maybe it can be made
optional or dynamic loaded in that one?) There seems to be other
configurations that are pulled from dbus, like the dbuspolicydir,
dbussessionservicedir, etc.
The current configure.ac logic is actually broken. We pretend that
dbus was optional, but we use it's pkg-config file to derive the
default paths you point out.

We should fix that. Happy to take a patch. Also added a TODO list item
for this.

Lennart
--
Lennart Poettering, Red Hat
Filipe Brandenburger
2014-10-23 11:06:18 UTC
Permalink
Hi Lennart,

On Wed, Oct 22, 2014 at 2:07 PM, Lennart Poettering
Post by Lennart Poettering
Post by Filipe Brandenburger
Indeed it would be good to clarify that libdbus is not required at
build time (except for the test case, and maybe it can be made
optional or dynamic loaded in that one?) There seems to be other
configurations that are pulled from dbus, like the dbuspolicydir,
dbussessionservicedir, etc.
The current configure.ac logic is actually broken. We pretend that
dbus was optional, but we use it's pkg-config file to derive the
default paths you point out.
We should fix that. Happy to take a patch. Also added a TODO list item
for this.
Last time I looked, I was under the impression that the dbus
pkg-config was also used to define some variables dbus* that defined
the /etc directories where some of the files were installed (in
particular, I recall the policykit files were on that list but I
believe there are more.)

I'll take a look at making the dbus dependency optional but I'll take
my time to make sure it's done right. Expect a patch sometime next
week.

Cheers,
Filipe
Lennart Poettering
2014-10-23 11:21:31 UTC
Permalink
Post by Filipe Brandenburger
Hi Lennart,
On Wed, Oct 22, 2014 at 2:07 PM, Lennart Poettering
Post by Lennart Poettering
Post by Filipe Brandenburger
Indeed it would be good to clarify that libdbus is not required at
build time (except for the test case, and maybe it can be made
optional or dynamic loaded in that one?) There seems to be other
configurations that are pulled from dbus, like the dbuspolicydir,
dbussessionservicedir, etc.
The current configure.ac logic is actually broken. We pretend that
dbus was optional, but we use it's pkg-config file to derive the
default paths you point out.
We should fix that. Happy to take a patch. Also added a TODO list item
for this.
Last time I looked, I was under the impression that the dbus
pkg-config was also used to define some variables dbus* that defined
the /etc directories where some of the files were installed (in
particular, I recall the policykit files were on that list but I
believe there are more.)
Yes, exactly, that is what I was saying.

The behaviour should really be to:

1. take the paths from configure switches
2. if they are not specified, try to get them from pkg-config
3. if the relevant pkg-config files are not installed, generate an error and refuse build

This way things should work smoothly without dbus/polkit/... around on
the build host as long as you specify the paths manually. But if you
don't and we cannot find them we'll rightfully fail.
Post by Filipe Brandenburger
I'll take a look at making the dbus dependency optional but I'll take
my time to make sure it's done right. Expect a patch sometime next
week.
Thanks, that would be great!

Lennart
--
Lennart Poettering, Red Hat
Simon McVittie
2014-10-23 11:44:09 UTC
Permalink
Post by Lennart Poettering
1. take the paths from configure switches
2. if they are not specified, try to get them from pkg-config
3. if the relevant pkg-config files are not installed, generate an error and refuse build
Actually... with D-Bus maintainer hat on, I think it's better for
non-dbus packages to use their own ${sysconfdir}/dbus-1/system.d,
${datadir}/dbus-1/services and so on, rather than querying dbus'
pkg-config file (analogous to the behaviour prescribed for XDG_DATA_DIRS
in the XDG basedir specification). That's what I recommended in the
D-Bus Specification.

I consider the dbus-1/services and dbus-1/system-services paths to be
part of D-Bus, and they are specifically described in the D-Bus
Specification. The status of ${sysconfdir}/dbus-1/system.d is a bit less
clear-cut, but if we ever changed it, we'd break every system service.

In particular, even if dbus-daemon is installed in /opt or something, it
is hard-coded to look for services in /usr/local and /usr as well as its
own ${prefix} (and the Specification says so). If someone is installing
software in a non-/usr tree, they're doing that because they want to
isolate it for whatever reason, and we probably shouldn't second-guess
that; if they want to search /opt/gnome (or whatever) in addition, it's
easy to configure dbus-daemon to do that, by dropping a file into system.d.

This seems doubly true for systemd, which is the sort of thing that
really ought to be installed to (/etc and) /usr by the distribution
vendor in any case, so the system dbus-daemon is always going to pick it up.

dbus-1.pc is mainly the pkg-config metadata for libdbus, the reference C
implementation of D-Bus. The abstract D-Bus protocol that has been
reimplemented by packages like dbus-sharp, dbus-java, GLib (GDBus) and
systemd (sd-bus) should not require use of libdbus, and libdbus isn't
even the implementation I recommend to most C authors (that would be
GLib's).

S
Lennart Poettering
2014-10-23 12:02:21 UTC
Permalink
Post by Simon McVittie
Post by Lennart Poettering
1. take the paths from configure switches
2. if they are not specified, try to get them from pkg-config
3. if the relevant pkg-config files are not installed, generate an error and refuse build
Actually... with D-Bus maintainer hat on, I think it's better for
non-dbus packages to use their own ${sysconfdir}/dbus-1/system.d,
${datadir}/dbus-1/services and so on, rather than querying dbus'
pkg-config file (analogous to the behaviour prescribed for XDG_DATA_DIRS
in the XDG basedir specification). That's what I recommended in the
D-Bus Specification.
I consider the dbus-1/services and dbus-1/system-services paths to be
part of D-Bus, and they are specifically described in the D-Bus
Specification. The status of ${sysconfdir}/dbus-1/system.d is a bit less
clear-cut, but if we ever changed it, we'd break every system service.
In particular, even if dbus-daemon is installed in /opt or something, it
is hard-coded to look for services in /usr/local and /usr as well as its
own ${prefix} (and the Specification says so). If someone is installing
software in a non-/usr tree, they're doing that because they want to
isolate it for whatever reason, and we probably shouldn't second-guess
that; if they want to search /opt/gnome (or whatever) in addition, it's
easy to configure dbus-daemon to do that, by dropping a file into system.d.
This seems doubly true for systemd, which is the sort of thing that
really ought to be installed to (/etc and) /usr by the distribution
vendor in any case, so the system dbus-daemon is always going to pick it up.
dbus-1.pc is mainly the pkg-config metadata for libdbus, the reference C
implementation of D-Bus. The abstract D-Bus protocol that has been
reimplemented by packages like dbus-sharp, dbus-java, GLib (GDBus) and
systemd (sd-bus) should not require use of libdbus, and libdbus isn't
even the implementation I recommend to most C authors (that would be
GLib's).
Makes sense I guess. Except for the bits in /etc that really should be
in /usr anyway...

I'd take a patch that removes the pkg-config hook-up for dbus entirely
from configure.ac then.

Lennart
--
Lennart Poettering, Red Hat
Filipe Brandenburger
2014-10-23 12:37:19 UTC
Permalink
Post by Lennart Poettering
Post by Simon McVittie
Actually... with D-Bus maintainer hat on, I think it's better for
non-dbus packages to use their own ${sysconfdir}/dbus-1/system.d,
${datadir}/dbus-1/services and so on, rather than querying dbus'
pkg-config file (analogous to the behaviour prescribed for XDG_DATA_DIRS
in the XDG basedir specification). That's what I recommended in the
D-Bus Specification.
Makes sense I guess. Except for the bits in /etc that really should be
in /usr anyway...
I'd take a patch that removes the pkg-config hook-up for dbus entirely
from configure.ac then.
Ack, will do.

Filipe

Filipe Brandenburger
2014-10-23 12:35:58 UTC
Permalink
On Thu, Oct 23, 2014 at 7:21 AM, Lennart Poettering
Post by Lennart Poettering
1. take the paths from configure switches
2. if they are not specified, try to get them from pkg-config
3. if the relevant pkg-config files are not installed, generate an error and refuse build
This way things should work smoothly without dbus/polkit/... around on
the build host as long as you specify the paths manually. But if you
don't and we cannot find them we'll rightfully fail.
Yes, I had something like that in mind. I was thinking of maybe
defaulting it to /etc/whatever, though I can see that failing if not
explicit or available from pkg-config would be better.
Post by Lennart Poettering
Post by Filipe Brandenburger
I'll take a look at making the dbus dependency optional but I'll take
my time to make sure it's done right. Expect a patch sometime next
week.
Thanks, that would be great!
Great, I'll make sure I test all the combinations and update the docs
and send you something when I'm happy with it.

Cheers,
Filipe
Continue reading on narkive:
Loading...