systemd-183

systemd-183

[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.

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

Re: systemd-183

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 451 bytes --]

On Thu, May 24, 2012 at 02:36:36PM -0500, Bruce Dubbs wrote:
> 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


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: systemd-183

[Karl O. Pinc]

On 05/26/2012 07:54:51 PM, William Hubbs wrote:

> 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 <kop@meme.com>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein

Re: systemd-183

[Bruce Dubbs]

Karl O. Pinc wrote:
> On 05/26/2012 07:54:51 PM, William Hubbs wrote:
> 
>> 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

Re: systemd-183

[Karl O. Pinc]

On 05/26/2012 10:38:30 PM, Bruce Dubbs wrote:

> 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: linux-hotplug@vger.kernel.org



Karl <kop@meme.com>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein

Re: systemd-183

[Kay Sievers]

On Sun, May 27, 2012 at 5:19 AM, Karl O. Pinc <kop@meme.com> wrote:
> On 05/26/2012 07:54:51 PM, William Hubbs wrote:
>
>> 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

Re: systemd-183

[Karl O. Pinc]

On 05/27/2012 06:34:11 AM, Kay Sievers wrote:

> 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 <kop@meme.com>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein

Re: systemd-183

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1289 bytes --]

Hi Kay,

On Sun, May 27, 2012 at 01:34:11PM +0200, Kay Sievers wrote:
> 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.

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


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: systemd-183

[Bruce Dubbs]

William Hubbs wrote:
> Hi Kay,
> 
> On Sun, May 27, 2012 at 01:34:11PM +0200, Kay Sievers wrote:
>> 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.
> 
> 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.

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

Re: systemd-183

[Tom Gundersen]

On Thu, May 31, 2012 at 9:33 PM, Bruce Dubbs <bruce.dubbs@gmail.com> wrote:
> 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

[0]: <http://www.archlinux.org/packages/core/any/hwids/>

Re: systemd-183

[Kay Sievers]

On Thu, May 31, 2012 at 9:46 PM, Tom Gundersen <teg@jklm.no> wrote:
> On Thu, May 31, 2012 at 9:33 PM, Bruce Dubbs <bruce.dubbs@gmail.com> wrote:
>> 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.

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

Re: systemd-183

[Kay Sievers]

On Thu, May 31, 2012 at 7:35 PM, William Hubbs <w.d.hubbs@gmail.com> wrote:

> 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

Re: systemd-183

[Bruce Dubbs]

Tom Gundersen wrote:
> On Thu, May 31, 2012 at 9:33 PM, Bruce Dubbs <bruce.dubbs@gmail.com> wrote:
>> 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.

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

Re: systemd-183

[Kay Sievers]

On Thu, May 31, 2012 at 10:30 PM, Bruce Dubbs <bruce.dubbs@gmail.com> wrote:
> Tom Gundersen wrote:
>>
>> On Thu, May 31, 2012 at 9:33 PM, Bruce Dubbs <bruce.dubbs@gmail.com>
>> wrote:
>>>
>>> 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.
>
>
> 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.

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

Re: systemd-183

[Tom Gundersen]

On Thu, May 31, 2012 at 9:57 PM, Kay Sievers <kay@vrfy.org> wrote:
> 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