2012/6/19 Kay Sievers <k...@vrfy.org> > 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. >
NOKIA married with M$ , so, this kdbus stuff is vanished, said. > > 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 >
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel