[systemd-devel] setting up to allow separate udev and systemd builds
m.olbrich at pengutronix.de
Tue Jun 19 09:36:39 PDT 2012
On Tue, Jun 19, 2012 at 01:59:14PM +0200, Kay Sievers wrote:
> 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
Well, source based distros typically try not to waste CPU cycles, because
at some point it just takes too long. Also, while I can skip installing the
systemd specific stuff, dbus libcap and expat are already there.
But more importantly I'm afraid that if we don't raise our concerns now,
that at some point glib isn't optional any more, for reasons much like
those stated in this thread.
> >> 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.
That would just make D-Bus a requirement for udev too. After all the D-Bus
dependency is for libdbus and not the daemon.
> 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.
Well I think that such a modularization should be the byproduct of a clean
design and architecture, but I guess that's a matter of opinion.
Does this mean that if I sent a patch that reorders things in configure.ac,
so that I only need to add one 'if ENABLE_SYSTEMD' afterwards, it has a
good chance that it's applied?
> We properly support *running* (and distros can do such packaging) a
Now it's "properly". Can we please get a clear answer here?
> 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.
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
More information about the systemd-devel