[systemd-devel] setting up to allow separate udev and systemd builds

[microcai]

2012/6/19 Kay Sievers <kay at vrfy.org>

> On Tue, Jun 19, 2012 at 1:10 PM, Michael Olbrich
> <m.olbrich at 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 (bryan at 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 at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20120620/f2bd329b/attachment-0001.html>