On Tue, Jun 19, 2012 at 1:10 PM, Michael Olbrich <m.olbr...@pengutronix.de> wrote: > On Tue, Jun 19, 2012 at 11:21:58AM +0200, Lennart Poettering wrote: >> On Fri, 15.06.12 20:06, Bryan Kadzban (br...@kadzban.is-a-geek.net) wrote: >> > dbus >> > libcap >> >> I am quite happy with depending on these two as it makes little sense to >> build an OS without it, unless you go super minimal in which case >> sysemd/udev are not relevant. > > For embedded distros udev without systemd is a very real usecase. > >> > m4 >> > intltool >> > gperf (--enable-keymap will require gperf for a udev build as well) >> >> These are only build-time deps, and hence are totally OK to have. > > I don't care about these. But cross-compiling dbus when it's not actually > wanted or needed is not ok.
There are zero known problems with doing that with D-Bus. All you do is waste CPU cycles on the build system, which is what we all do anyway when we do your own stuff and don't use a pre-compiled package from a distro. I really don't see a problem here besides some inconvenience, which is justified at this moment, where everything is just newly introduced stuff. >> I mean, the next thing you come up with is a patch to not require >> automake and use only make, just because you have a problem with >> dependencies? I mean, seriously. > > This is uncalled for. Depending on a good build-system is ok. But it was > clearly stated that using udev without systemd will still be possible. I > don't see why it should not be possible to build udev without systemd and > therefore any extra dependencies. We said udev *runs* alone, not that you can tweak the build system to only build it. And that is still all true. Without patching the build sys, you can *probably* temporarily work around the build dependencies with things like: $ export PKG_CONFIG_PATH=$PWD; \ echo -e "Name: dbus-1\nDescription: stub\nVersion: 999" > dbus-1.pc $ ./configure $ make systemd-udevd udevadm ata_id .... Longer-term plan is to move the D-Bus daemon functionality to the kernel, and let systemd talk directly to the kernel. The external D-Bus dependency might go entirely away with that. At that point, when there is no D-Bus daemon runtime dependency anymore, it is very likely that udevd/udevadm/libudev will use the kernel's D-Bus interfaces too instead of the home-grown IPC, and all of that build-sys splitting and fiddling makes not much sense anymore. So, please keep that build-sys stuff local please and do not expect any of this to be merged upstream at this moment. We can merge reasonable and obvious patches to make things easier, like we removed the needless D-Bus tools linking for the udev binaries, but we do not want to make promises about full modularization, or things like disabling the build of systemd in the systemd tarball. We properly support *running* (and distros can do such packaging) a standalone udev, for people who run systems without systemd. We just do not support fully separated standalone *builds* at the moment, and maybe we never will. If things turn out differently in the future as we expect them to be, we can discuss that again, but that is unlikely to happen before the end of the year. We first need to see where we will end up with D-Bus when we get there, it might change all the assumptions people make about this sort dependency so far. Thanks, Kay _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel