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 > 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. 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. (Previously, packages could dump a device node into /lib/udev/devices and it would show up on every boot. Now, they have to describe the device node and dump a file into $(tmpfilesdir), wherever that happens to be. This is obviously an interface change.) -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
