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

[Kay Sievers]

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.

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