systemd-183
I see that systemd-183 is out in the
http://www.freedesktop.org/software/systemd/ repository.
My understanding is that this version of systemd has udev included.
I've looked through the NEWS, README, and ./configure --help.
How do I build udev without systemd? Failing that, how do I install just udev without systend?
Or will there be a separate udev distribution?
-- Bruce Dubbs
Linux From Scratch
Quoted 6 lines · Bruce Dubbs
I see that systemd-183 is out in the
http://www.freedesktop.org/software/systemd/ repository.My understanding is that this version of systemd has udev included.
I've looked through the NEWS, README, and ./configure --help.
I have the same questions. I don't want to do a full systemd build just to install udev. Is there some way to build udev only?
William
Quoted 3 lines · William Hubbs
I have the same questions. I don't want to do a full systemd build just
to install udev. Is there some way to build udev only?
I don't recall how to do it, but when the merge into systemd was announced there were instructions for building just udev.
See the mailing list archives.
Karl <[email protected]>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
Quoted 10 lines · Karl O. Pinc
Quoted 3 lines · William Hubbs
I have the same questions. I don't want to do a full systemd build just
to install udev. Is there some way to build udev only?I don't recall how to do it, but when the merge into systemd was announced there were instructions for building just udev.
See the mailing list archives.
I looked at the systemd mailing list and I cannot find any such instructions. The announce message was only yesterday.
I'd appreciate a pointer.
The announcement I found was on the freedesktop.org systemd-devel list.
Is this mailing list going to be abandoned?
-- Bruce
Quoted 4 lines · Bruce Dubbs
I looked at the systemd mailing list and I cannot find any such instructions. The announce message was only yesterday.
I'd appreciate a pointer.
The udev mailing list: [email protected]
Karl <[email protected]>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
Quoted 10 lines · Karl O. Pinc
Quoted 3 lines · William Hubbs
I have the same questions. I don't want to do a full systemd build just
to install udev. Is there some way to build udev only?I don't recall how to do it, but when the merge into systemd was announced there were instructions for building just udev.
See the mailing list archives.
We support stand-alone *operation* of the udev tools, but the build system does not support a stand-alone *build*. The systemd tree needs to be built and udev picked out of it.
There are also several other generally useful tools in the built tree, which you might need too over time, like tmpfiles, module-load, sysconf, binfmt, ... A couple of D-Bus services to manage system settings from the desktop.
Various upstream tools start to install config files or use these interfaces. It might be the simplest to install them too, even when systemd is not used.
Kay
Quoted 2 lines · Kay Sievers
We support stand-alone *operation* of the udev tools, but the build system does not support a stand-alone *build*.
Sorry. I got it wrong.
Karl <[email protected]>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
Hi Kay,
Quoted 4 lines · Kay Sievers
We support stand-alone *operation* of the udev tools, but the build system does not support a stand-alone *build*. The systemd tree needs to be built and udev picked out of it.
Quoted 8 lines
There are also several other generally useful tools in the built tree, which you might need too over time, like tmpfiles, module-load, sysconf, binfmt, ... A couple of D-Bus services to manage system settings from the desktop.
Various upstream tools start to install config files or use these interfaces. It might be the simplest to install them too, even when systemd is not used.
I understand that folks might want these tools, but I don't want to install the ones that udev doesn't need as part of the udev package. I am also concerned about libcap and dbus being hard requirements of the udev build process.
If udev, or the tools that it needs, like tmpfiles, requires these libraries, that is one thing, otherwise I really do not want to make them dependencies of the udev package. The issue is that in gentoo, since we are source based, I would have to require all of our users to install dbus and libcap just to build udev.
Do you have any suggestions?
Thanks,
William
Quoted 21 lines · William Hubbs
Hi Kay,
Quoted 4 lines · Kay Sievers
We support stand-alone *operation* of the udev tools, but the build system does not support a stand-alone *build*. The systemd tree needs to be built and udev picked out of it.
Quoted 8 lines
There are also several other generally useful tools in the built tree, which you might need too over time, like tmpfiles, module-load, sysconf, binfmt, ... A couple of D-Bus services to manage system settings from the desktop.
Various upstream tools start to install config files or use these interfaces. It might be the simplest to install them too, even when systemd is not used.
I understand that folks might want these tools, but I don't want to install the ones that udev doesn't need as part of the udev package. I am also concerned about libcap and dbus being hard requirements of the udev build process.
Quoted 5 lines
If udev, or the tools that it needs, like tmpfiles, requires these libraries, that is one thing, otherwise I really do not want to make them dependencies of the udev package. The issue is that in gentoo, since we are source based, I would have to require all of our users to install dbus and libcap just to build udev.
The Linux From Scratch community has the same problem. We are working on this in two ways.
1. I've developed a make.sh script and an install.sh script to build, link, and install udev from the systemd sources bypassing the autotools environment completely. This is not desirable, but it gets the job done and is a proof of concept.
2. We are working to modify configure.ac and Makefile.in to do the right thing. That may take a little more time.
I can say that there are several packages currently required by configure that are not needed by a udev only build: intltool, XML::Parser, libpcap2, attr, usbutils, libusb, pciutils, and dbus.
The common/systemd files needed for the udev applications are:
src/shared:log.c label.c mkdir.c cgroup-util.c strv.c path-util.c conf-files.c hashmap.c set.c exit-status.c util.c dev-setup.c
src/libsystemd-daemon:sd-daemon.c
src/login:sd-login.c
If those files are built and put into a separate library, it would make the rest of a udev only build much more straight forward.
I'll get back to this list when we have more progress.
-- Bruce
Quoted 3 lines · Bruce Dubbs
I can say that there are several packages currently required by configure that are not needed by a udev only build: Â intltool,
XML::Parser, libpcap2, attr, usbutils, libusb, pciutils, and dbus.
Regarding usbutils and pciutils: these are not needed at compile-time if you pass in the correct configure switch to set the {pci,usb}ids path.
The {pci,usb}ids databases are however needed by udev on runtime and they are traditionally shipped with {usb,pci}utils, so that's something to keep in mind.
On Arch (as well as on Gentoo), we deal with this by shipping the databases in a separate package[0], and dropping the dependency on {pci,usb}utils. Maybe that's something other's would benefit from too.
Cheers,
Tom
Quoted 9 lines · Tom Gundersen
Quoted 3 lines · Bruce Dubbs
I can say that there are several packages currently required by configure that are not needed by a udev only build: Â intltool,
XML::Parser, libpcap2, attr, usbutils, libusb, pciutils, and dbus.Regarding usbutils and pciutils: these are not needed at compile-time if you pass in the correct configure switch to set the {pci,usb}ids path.
Quoted 7 lines
The {pci,usb}ids databases are however needed by udev on runtime and they are traditionally shipped with {usb,pci}utils, so that's something to keep in mind.
On Arch (as well as on Gentoo), we deal with this by shipping the databases in a separate package[0], and dropping the dependency on {pci,usb}utils. Maybe that's something other's would benefit from too.
It's probably not worth to put too much effort into it. We are about to make a more generic query-able hardware database with pre-compiled efficient lookup interfaces. It will provide additional key/value pairs that further classify devices we care about. All this will go far beyond the human readable strings the ids files provide.
Just saying, pretty soon, the ids files will no longer directly read by udev. We will see how all that will look like when we get there.
Kay
Quoted 6 lines · William Hubbs
I am also concerned about libcap and dbus being hard requirements of the udev build process.
The issue is that in
gentoo, since we are source based, I would have to require all of our users to install dbus and libcap just to build udev.
Libcap should be gone with the one include Bryan patched out.
D-Bus should no longer be pulled into the shared stuff udev needs, but the build-sys still requires D-Bus at configure time.
Kay
Quoted 9 lines · Tom Gundersen
Quoted 3 lines · Bruce Dubbs
I can say that there are several packages currently required by configure that are not needed by a udev only build: intltool,
XML::Parser, libpcap2, attr, usbutils, libusb, pciutils, and dbus.Regarding usbutils and pciutils: these are not needed at compile-time if you pass in the correct configure switch to set the {pci,usb}ids path.
Quoted 7 lines
The {pci,usb}ids databases are however needed by udev on runtime and they are traditionally shipped with {usb,pci}utils, so that's something to keep in mind.
On Arch (as well as on Gentoo), we deal with this by shipping the databases in a separate package[0], and dropping the dependency on {pci,usb}utils. Maybe that's something other's would benefit from too.
We may have been doing it incorrectly, but we've used
--with-usb-ids-path=no
--with-pci-ids-path=no
in LFS for some time with udev. No one has reported any problems with that, but there may have been some latent issues we are not aware of.
-- Bruce
Quoted 24 lines · Bruce Dubbs
Quoted 14 lines · Tom Gundersen
Quoted 5 lines · Bruce Dubbs
I can say that there are several packages currently required by configure that are not needed by a udev only build: intltool,
XML::Parser, libpcap2,
attr, usbutils, libusb, pciutils, and dbus.Regarding usbutils and pciutils: these are not needed at compile-time if you pass in the correct configure switch to set the {pci,usb}ids path.
Quoted 7 lines
The {pci,usb}ids databases are however needed by udev on runtime and they are traditionally shipped with {usb,pci}utils, so that's something to keep in mind.
On Arch (as well as on Gentoo), we deal with this by shipping the databases in a separate package[0], and dropping the dependency on {pci,usb}utils. Maybe that's something other's would benefit from too.
Quoted 7 lines
We may have been doing it incorrectly, but we've used
--with-usb-ids-path=no
--with-pci-ids-path=noin LFS for some time with udev. No one has reported any problems with that, but there may have been some latent issues we are not aware of.
Nothing should go wrong.
It's only that some user interfaces want to be nice and show the 'real' name of the devices. But if the ids databases are not around, they will fall back to things like "Audio Device" instead of "Intel HDA Audio" and such.
Kay
Quoted 8 lines · Kay Sievers
It's probably not worth to put too much effort into it. We are about to make a more generic query-able hardware database with pre-compiled efficient lookup interfaces. It will provide additional key/value pairs that further classify devices we care about. All this will go far beyond the human readable strings the ids files provide.
Just saying, pretty soon, the ids files will no longer directly read by udev. We will see how all that will look like when we get there.
That makes a lot of sense. Hopefully it will be similar to the hwids package from a packaging point of view (i.e. a standalone db that can be shipped independently from any libs/tools).
Cheers,
Tom