Linux Hotplug development

Bryan Kadzban | 2 Jun 2012 08:56

[PATCH] Allow disabling the build of all of systemd, leaving just udev

Add a new ./configure arg (--disable-systemd) that causes the build
system to build, test, and install only udev.

Allows udev to be built on a system with many fewer of the build-time
dependencies present.

Signed-Off-By: Bryan Kadzban <bryan <at> kadzban.is-a-geek.net>

----

Possible points of discussion:

Should this flag be called --disable-systemd, as I did?  (That follows
the autoconf docs, which say --disable-* should only ever turn stuff
off, and --enable-* should only ever turn stuff on.)  Or are the
autoconf docs irrelevant, and this should be called --enable-udev-only
or something, instead?  The flag name isn't terribly important to me.

(Note that the flag is set to *enable* systemd by default.  Disabling it
is probably not to be done lightly, and a bunch of other stuff needs to
be turned off as well for this to actually build.)

Also, a few notes on usage.  First, to fully avoid installing systemd
stuff, a bunch of directories need to be set to the empty string at
"make install" time, or they'll be created and left empty.
("pkgdatadir= polkitpolicydir= bashcompletiondir= pkgsysconfdir=
userunitdir= tmpfilesdir= sysctldir= systemunitdir= pkgincludedir=
systemgeneratordir=" is the full list.)

Second, "make check" fails in the po/ directory if systemd was not

(Continue reading)

William Hubbs | 2 Jun 2012 22:49

Picon

Re: [PATCH] Allow disabling the build of all of systemd, leaving just udev

Hi Bryan,

this looks good to me, but there are still pieces being installed which
should not be installed for a udev-only build afaik.

You might want to look at removing those also.

Thanks,

William

Bryan Kadzban | 3 Jun 2012 18:55

Re: [PATCH] Allow disabling the build of all of systemd, leaving just udev

William Hubbs wrote:
> this looks good to me, but there are still pieces being installed
> which should not be installed for a udev-only build afaik.
> 
> You might want to look at removing those also.

Which pieces?

The only things that get installed in my case are the rules, udev.conf,
systemd-udevd, udevadm, the helper binaries, the manpages, libudev, the
udev and libudev pkg-config files, and stuff in /usr/share/doc.  Though
I do use a lot of the existing ./configure knobs to turn other systemd
things off; maybe that's related.

Unless you mean the directories that are getting created, as in the
previous message -- but I don't see a way to stop automake from doing
that.  Well, other than setting them to nothing in the Makefile.am if
!ENABLE_SYSTEMD; duh, I should have done that.  But that still seems a
bit cosmetic to me.

(One thing I need to do today is fix this so that "make distdir" works
even with --disable-systemd.  Should be able to pull the EXTRA_DIST
stuff out of the conditionals to do that.  So I'll probably look into
setting these directories to nothing in that case as well.)
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

(Continue reading)

Bryan Kadzban | 3 Jun 2012 23:21

Re: [PATCH] Allow disabling the build of all of systemd, leaving just udev

Bryan Kadzban wrote:
> Unless you mean the directories that are getting created, as in the 
> previous message -- but I don't see a way to stop automake from doing
> that.

Digging a bit (the initial attempt at setting directories to "" resulted
in several warnings from automake about conditionally changing pkg*dir
variables), recent versions of automake no longer create empty
directories.  Upgrading my system to 1.12.1 (most recent) and rerunning
"autoreconf --force" removed almost all of the requirements to set these
directories to the empty string.

I still need to set "pkgincludedir= pkgsysconfdir=", and that looks like
a too-simple check for no files (it doesn't work if there's only
whitespace).  But I don't think it's a huge deal either.

> (One thing I need to do today is fix this so that "make distdir"
> works even with --disable-systemd.)

This is now done, just without the directory changes, since a newer
automake fixes that.  v2 patch (including header) attached.

Still wondering which bits of systemd got installed in your setup
though.

Add a new ./configure arg (--disable-systemd) that causes the build
system to build, test, and install only udev.

Allows udev to be built on a system with many fewer of the build-time

(Continue reading)

William Hubbs | 3 Jun 2012 23:22

Picon

Re: [PATCH] Allow disabling the build of all of systemd, leaving just udev

On Sun, Jun 03, 2012 at 09:55:55AM -0700, Bryan Kadzban wrote:
> William Hubbs wrote:
> > this looks good to me, but there are still pieces being installed
> > which should not be installed for a udev-only build afaik.
> > 
> > You might want to look at removing those also.
> 
> Which pieces?
> 
> The only things that get installed in my case are the rules, udev.conf,
> systemd-udevd, udevadm, the helper binaries, the manpages, libudev, the
> udev and libudev pkg-config files, and stuff in /usr/share/doc.  Though
> I do use a lot of the existing ./configure knobs to turn other systemd
> things off; maybe that's related.

Maybe it is, because I get the following things that would also be
installed:

etc/bash_completion.d
etc/systemd
usr/include/systemd
usr/lib/sysctl.d
usr/lib/systemd/system-generators
usr/lib/systemd/user
usr/share/man/man1
usr/share/man/man3
usr/share/man/man5
usr/share/polkit-1
usr/share/polkit-1/actions
usr/share/systemd

(Continue reading)

Bryan Kadzban | 4 Jun 2012 00:00

Re: [PATCH] Allow disabling the build of all of systemd, leaving just udev

William Hubbs wrote:
> On Sun, Jun 03, 2012 at 09:55:55AM -0700, Bryan Kadzban wrote:
>> Which pieces?
> 
> etc/bash_completion.d
> etc/systemd
> usr/include/systemd
> usr/lib/sysctl.d
> usr/lib/systemd/system-generators
> usr/lib/systemd/user
> usr/share/man/man1
> usr/share/man/man3
> usr/share/man/man5
> usr/share/polkit-1
> usr/share/polkit-1/actions
> usr/share/systemd

Those are all the empty directories that a newer automake will get rid
of, except two. You can suppress those at install time with:

make pkgincludedir= pkgsysconfdir= install

I can't fix pkgincludedir without warnings from automake (since it's
unconditionally set to $(includedir)/$(PACKAGE), and overriding it in
different branches of a conditional generates warnings), so I didn't fix
either of them.

> One more thing though, thinking about it, is that we will need the
> systemd-tmpfiles tool because udev is not going to support the
> /lib/udev/devices directory any longer for creating custom devices, so

(Continue reading)

William Hubbs | 4 Jun 2012 03:50

Picon

Re: [PATCH] Allow disabling the build of all of systemd, leaving just udev

On Sun, Jun 03, 2012 at 03:00:27PM -0700, Bryan Kadzban wrote:
> > One more thing though, thinking about it, is that we will need the
> > systemd-tmpfiles tool because udev is not going to support the
> > /lib/udev/devices directory any longer for creating custom devices, so
> > you might want to still build and install all of the parts of that for a
> > standalone udev build if doing so doesn't bring in more dependencies.
> 
> I'd rather not replace "cp -a /lib/udev/devices/* /dev" in a boot script
> with a binary that nothing else uses, plus its configuration (which
> doesn't use nodes in /lib/udev/devices like what has been the udev ABI
> for *years*, but instead uses a list of device descriptions), plus any
> systemd-level libraries it may or may not need in the future.

Actually other things could use it because of /tmp and /run and
creating/removing files/directories there on bootup.

> If a system is already running systemd, then systemd-tmpfiles may or may
> not be the best place to do this (the ABI change is a problem for those
> systems, unless I'm missing something in the *tmpfiles* manpages). But
> if systemd is not running, then sticking to the previous ABI explicitly
> is the right way to go I think.

Unless you don't have a previous abi. Gentoo relies on udev copying
things from /lib/udev/devices, which is gone with this version of udev,
so we need the new abi.

So, how about an extra switch --enable-tmpfiles-d that will toggle on or
off whether that is built on a standalone udev build?

William

(Continue reading)

Bryan Kadzban | 4 Jun 2012 04:13

Re: [PATCH] Allow disabling the build of all of systemd, leaving just udev

William Hubbs wrote:
> On Sun, Jun 03, 2012 at 03:00:27PM -0700, Bryan Kadzban wrote:
>> I'd rather not replace "cp -a /lib/udev/devices/* /dev" in a boot
>> script with a binary that nothing else uses, plus its configuration
>> (which doesn't use nodes in /lib/udev/devices like what has been
>> the udev ABI for *years*, but instead uses a list of device
>> descriptions), plus any systemd-level libraries it may or may not
>> need in the future.
> 
> Actually other things could use it because of /tmp and /run and 
> creating/removing files/directories there on bootup.

Possibly, but the full functionality will require systemd anyway.  The
program still has to be run by something; simply installing it won't do
anything useful.  Plus it will have to depend on having mounted the
various temporary filesystems that it changes.

>> If a system is already running systemd, then systemd-tmpfiles may
>> or may not be the best place to do this (the ABI change is a
>> problem for those systems, unless I'm missing something in the
>> *tmpfiles* manpages). But if systemd is not running, then sticking
>> to the previous ABI explicitly is the right way to go I think.
> 
> Unless you don't have a previous abi.

Except that udev-182 and earlier *provided* an ABI.  "Put files in
/lib/udev/devices and they'll be copied to /dev at boot time" was the
rule, just like "put programs in /lib/udev and refer to them in rules
you install with IMPORT{program}="" or RUN+="" without a path" was the
rule.

(Continue reading)

William Hubbs | 4 Jun 2012 20:51

Picon

Re: [PATCH] Allow disabling the build of all of systemd, leaving just udev

On Sun, Jun 03, 2012 at 07:13:03PM -0700, Bryan Kadzban wrote:
> William Hubbs wrote:
> > On Sun, Jun 03, 2012 at 03:00:27PM -0700, Bryan Kadzban wrote:
> >> I'd rather not replace "cp -a /lib/udev/devices/* /dev" in a boot
> >> script with a binary that nothing else uses, plus its configuration
> >> (which doesn't use nodes in /lib/udev/devices like what has been
> >> the udev ABI for *years*, but instead uses a list of device
> >> descriptions), plus any systemd-level libraries it may or may not
> >> need in the future.
> > 
> > Actually other things could use it because of /tmp and /run and 
> > creating/removing files/directories there on bootup.
> 
> Possibly, but the full functionality will require systemd anyway.  The
> program still has to be run by something; simply installing it won't do
> anything useful.  Plus it will have to depend on having mounted the
> various temporary filesystems that it changes.

I agree that just installing it does nothing. But, it can be run at the
appropriate time by your boot scripts, so the other concerns you mention
here would be taken care of that way.

> >> If a system is already running systemd, then systemd-tmpfiles may
> >> or may not be the best place to do this (the ABI change is a
> >> problem for those systems, unless I'm missing something in the
> >> *tmpfiles* manpages). But if systemd is not running, then sticking
> >> to the previous ABI explicitly is the right way to go I think.
> > 
> > Unless you don't have a previous abi.
>

(Continue reading)

Bryan Kadzban | 5 Jun 2012 05:10

Re: [PATCH] Allow disabling the build of all of systemd, leaving just udev

William Hubbs wrote:
> On Sun, Jun 03, 2012 at 07:13:03PM -0700, Bryan Kadzban wrote:
>> William Hubbs wrote:
>>> Actually other things could use it because of /tmp and /run and 
>>> creating/removing files/directories there on bootup.
>> Possibly, but the full functionality will require systemd anyway.
>> The program still has to be run by something; simply installing it
>> won't do anything useful.  Plus it will have to depend on having
>> mounted the various temporary filesystems that it changes.
> 
> I agree that just installing it does nothing. But, it can be run at
> the appropriate time by your boot scripts, so the other concerns you
> mention here would be taken care of that way.

Why put effort into bootscripts that run a random other tool, when
instead we can resurrect the single line cp from a few years back?

It's somewhat annoying that we have to do anything, but that's what happens.

>> Except that udev-182 and earlier *provided* an ABI.  "Put files in 
>> /lib/udev/devices and they'll be copied to /dev at boot time" was
>> the rule, just like "put programs in /lib/udev and refer to them in
>> rules you install with IMPORT{program}="" or RUN+="" without a
>> path" was the rule.
>> 
>> Now that rule has apparently been changed, so programs are going to
>> have to expend effort coping.  Unless I'm missing some
>> functionality of systemd-tmpfiles when I read the docs.
> 
> It has definitely been changed. See the systemd NEWS file. That is

(Continue reading)

William Hubbs | 5 Jun 2012 19:56

Picon

Re: [PATCH] Allow disabling the build of all of systemd, leaving just udev

Hi Bryan,

On Mon, Jun 04, 2012 at 08:10:28PM -0700, Bryan Kadzban wrote:
> If you want to try to get systemd-tmpfiles to work, and figure out which
> extra dependencies are needed (like, oh for instance, selinux or
> libcap), feel free; that patch shouldn't be too hard to apply on top of
> this one, if this gets committed.

 I spoke with Kay on irc, and he expressed doubts that it will be
 committed. However, I did get another suggestion from one of the guys
 there.

 Automake supports includes, so it would be good to break up Makefile.am
 into several modules. That way it would be easy to include them based
 on condissionals.

 I have started breaking things apart, but if you want, I can send you
 the patch as I have it so far and we can collaborate on it. 

 William

Bryan Kadzban | 6 Jun 2012 05:45

Re: [PATCH] Allow disabling the build of all of systemd, leaving just udev

William Hubbs wrote:
> I spoke with Kay on irc, and he expressed doubts that it will be 
> committed.

Not being terribly inclined to set up an IRC client, were there any
issues with the patch itself?  Or does he just not like the idea at all
for some reason?  (Er, Kay?  Maybe I should ask you directly.   )

> However, I did get another suggestion from one of the guys there.
> 
> Automake supports includes, so it would be good to break up 
> Makefile.am into several modules. That way it would be easy to 
> include them based on condissionals.
> 
> I have started breaking things apart, but if you want, I can send you
> the patch as I have it so far and we can collaborate on it. 

Sure, we can start poking at it off-list.  Though I don't have more than
a few hours a day to put into it.  

(That does sound like a lot less-invasive of a change, once the files
are split.)
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Bruce Dubbs | 6 Jun 2012 06:23

Picon

Re: [PATCH] Allow disabling the build of all of systemd, leaving just udev

Bryan Kadzban wrote:
> William Hubbs wrote:
>> I spoke with Kay on irc, and he expressed doubts that it will be 
>> committed.
> 
> Not being terribly inclined to set up an IRC client, were there any
> issues with the patch itself?  Or does he just not like the idea at all
> for some reason?  (Er, Kay?  Maybe I should ask you directly.   )
> 
>> However, I did get another suggestion from one of the guys there.
>>
>> Automake supports includes, so it would be good to break up 
>> Makefile.am into several modules. That way it would be easy to 
>> include them based on condissionals.
>>
>> I have started breaking things apart, but if you want, I can send you
>> the patch as I have it so far and we can collaborate on it. 

I'm interested in this too.  However, I'm not sure what you are 
referring to when you mention modules.  Do you mean the automake 
instruction 'include'?

The problem with udev as it's currently embedded in systemd is that the 
udev programs require several systemd .c utility programs, although they 
all build without the problematic libraries required by systemd 
(intltool, d-bus, etc).  These object files could be combined into each 
of the udev programs without problems, but I'm having a problem 
understanding the concept of what is acceptable.

AFAICT, there still needs to be a change to configure.ac to optionally

(Continue reading)

William Hubbs | 6 Jun 2012 18:52

Picon

Re: [PATCH] Allow disabling the build of all of systemd, leaving just udev

On Tue, Jun 05, 2012 at 11:23:47PM -0500, Bruce Dubbs wrote:
> Bryan Kadzban wrote:
> > William Hubbs wrote:
> >> I spoke with Kay on irc, and he expressed doubts that it will be 
> >> committed.
> > 
> > Not being terribly inclined to set up an IRC client, were there any
> > issues with the patch itself?  Or does he just not like the idea at all
> > for some reason?  (Er, Kay?  Maybe I should ask you directly.   )
> > 
> >> However, I did get another suggestion from one of the guys there.
> >>
> >> Automake supports includes, so it would be good to break up 
> >> Makefile.am into several modules. That way it would be easy to 
> >> include them based on condissionals.
> >>
> >> I have started breaking things apart, but if you want, I can send you
> >> the patch as I have it so far and we can collaborate on it. 
> 
> I'm interested in this too.  However, I'm not sure what you are 
> referring to when you mention modules.  Do you mean the automake 
> instruction 'include'?

Yes, that's correct. I am thinking we can break up the makefile using
includes then include them based on configure switches.

> AFAICT, there still needs to be a change to configure.ac to optionally 
> avoid all the extras that systemd needs.  That seems to be where to 
> start, but we need support from upstream to get these changes into the 
> main distribution.

(Continue reading)

Dan Nicholson | 6 Jun 2012 14:38

Picon

Re: [PATCH] Allow disabling the build of all of systemd, leaving just udev

On Tue, Jun 5, 2012 at 10:56 AM, William Hubbs <w.d.hubbs <at> gmail.com> wrote:
> Hi Bryan,
>
> On Mon, Jun 04, 2012 at 08:10:28PM -0700, Bryan Kadzban wrote:
>> If you want to try to get systemd-tmpfiles to work, and figure out which
>> extra dependencies are needed (like, oh for instance, selinux or
>> libcap), feel free; that patch shouldn't be too hard to apply on top of
>> this one, if this gets committed.
>
>  I spoke with Kay on irc, and he expressed doubts that it will be
>  committed. However, I did get another suggestion from one of the guys
>  there.
>
>  Automake supports includes, so it would be good to break up Makefile.am
>  into several modules. That way it would be easy to include them based
>  on condissionals.

Breaking up the Makefile.am into several files is probably cleaner,
but it doesn't actually change the problem you're trying to solve
here. You still have to wrap large parts of the build in
AM_CONDITIONALs. That doesn't change whether it's in one file or many.
The include happens at automake time, not build time, so conditionally
including the file won't do anything different for you. Everything
will get merge into the toplevel Makefile.in.

--
Dan
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to majordomo <at> vger.kernel.org

(Continue reading)

William Hubbs | 6 Jun 2012 19:15

Picon

Re: [PATCH] Allow disabling the build of all of systemd, leaving just udev

On Wed, Jun 06, 2012 at 05:38:29AM -0700, Dan Nicholson wrote:
> Breaking up the Makefile.am into several files is probably cleaner,
> but it doesn't actually change the problem you're trying to solve
> here. You still have to wrap large parts of the build in
> AM_CONDITIONALs. That doesn't change whether it's in one file or many.
> The include happens at automake time, not build time, so conditionally
> including the file won't do anything different for you. Everything
> will get merge into the toplevel Makefile.in.

If the am_condissionals are controlled by configure switches, we can set
things up so that the packager or user who is building udev or systemd
has control over what gets built. If they want to build udev only, or
systemd, or just the tools in the distribution that don't require
systemd, they will be able to.

This is where I want to go once we have the Makefile broken up. This
will also require some work in configure.ac, but I think it will be
worth that because it will give packagers the flexability to build what
they want.

include Makefile-shared.am
if ENABLE_UDEV
include Makefile-udev.am
endif
if ENABLE_TOOLS
include Makefile-tools.am
endif
if ENABLE_SYSTEMD
include Makefile-systemd.am
endif

(Continue reading)

Bruce Dubbs | 6 Jun 2012 20:51

Picon

Re: [PATCH] Allow disabling the build of all of systemd, leaving just udev

William Hubbs wrote:

> This is where I want to go once we have the Makefile broken up. This
> will also require some work in configure.ac, but I think it will be
> worth that because it will give packagers the flexability to build what
> they want.
> 
> include Makefile-shared.am
> if ENABLE_UDEV
> include Makefile-udev.am
> endif
> if ENABLE_TOOLS
> include Makefile-tools.am
> endif
> if ENABLE_SYSTEMD
> include Makefile-systemd.am
> endif

With this type of setup, ENABLE_SYSTEMD must imply ENABLE_TOOLS and 
ENABLE_UDEV.

> The first stage of this will be breaking up Makefile.am and using
> includes without condissionals. Once everything builds cleanly in that
> setup, we can  do the work in configure.ac and add condissionals to
> Makefile.am.

The first thing that will have to be done is to break up 
libsystemd_shared_la_SOURCES in Makefile.am.  That definition combines 
files incompatible with udev-only with files required by udev.  udev needs:

(Continue reading)

William Hubbs | 7 Jun 2012 00:53

Picon

Re: [PATCH] Allow disabling the build of all of systemd, leaving just udev

On Wed, Jun 06, 2012 at 01:51:05PM -0500, Bruce Dubbs wrote:
> William Hubbs wrote:
> 
> With this type of setup, ENABLE_SYSTEMD must imply ENABLE_TOOLS and 
> ENABLE_UDEV.

What I want is for all of the enable_* options to be true by default so
that we don't affect the result of the build unless a packager requests
it by disabling portions.

My goal for the tools option is to find the things in the distribution
that can be useful whether or not your distro is using systemd and set
up so you can build those separately from systemd and udev if you aren't
quite ready to make the jump to systemd.

> The first thing that will have to be done is to break up 
> libsystemd_shared_la_SOURCES in Makefile.am.  That definition combines 
> files incompatible with udev-only with files required by udev.  udev needs:
> 
> log
> label
> mkdir
> cgroup-util
> strv
> path-util
> conf-files
> hashmap
> set
> exit-status
> util

(Continue reading)

Dan Nicholson | 7 Jun 2012 15:34

Picon

Re: [PATCH] Allow disabling the build of all of systemd, leaving just udev

On Wed, Jun 6, 2012 at 10:15 AM, William Hubbs <w.d.hubbs <at> gmail.com> wrote:
> On Wed, Jun 06, 2012 at 05:38:29AM -0700, Dan Nicholson wrote:
>> Breaking up the Makefile.am into several files is probably cleaner,
>> but it doesn't actually change the problem you're trying to solve
>> here. You still have to wrap large parts of the build in
>> AM_CONDITIONALs. That doesn't change whether it's in one file or many.
>> The include happens at automake time, not build time, so conditionally
>> including the file won't do anything different for you. Everything
>> will get merge into the toplevel Makefile.in.
>
> If the am_condissionals are controlled by configure switches, we can set
> things up so that the packager or user who is building udev or systemd
> has control over what gets built. If they want to build udev only, or
> systemd, or just the tools in the distribution that don't require
> systemd, they will be able to.
>
> This is where I want to go once we have the Makefile broken up. This
> will also require some work in configure.ac, but I think it will be
> worth that because it will give packagers the flexability to build what
> they want.
>
> include Makefile-shared.am
> if ENABLE_UDEV
> include Makefile-udev.am
> endif
> if ENABLE_TOOLS
> include Makefile-tools.am
> endif
> if ENABLE_SYSTEMD
> include Makefile-systemd.am

(Continue reading)

Return

Return to gmane.linux.hotplug.devel.

Project Web Page

Linux Hotplug development

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane