[1/1] WIP: libudev: New package

Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
---
 package/Config.in          |    1 +
 package/libudev/Config.in  |    9 +++++++++
 package/libudev/libudev.mk |   43 +++++++++++++++++++++++++++++++++++++++++++
 3 files changed, 53 insertions(+)
 create mode 100644 package/libudev/Config.in
 create mode 100644 package/libudev/libudev.mk

Bernd, All,

On 2014-05-26 20:31 +0200, Bernd Kuhls spake thusly:
> 
> Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
[--SNIP--]
> diff --git a/package/libudev/Config.in b/package/libudev/Config.in
> new file mode 100644
> index 0000000..f3f1b59
> --- /dev/null
> +++ b/package/libudev/Config.in
> @@ -0,0 +1,9 @@
> +config BR2_PACKAGE_LIBUDEV
> +	bool "libudev"
> +	depends on !BR2_INIT_SYSTEMD
> +	depends on !BR2_PACKAGE_EUDEV

Maybe replace those two 'depends on' with simply:

    depends on !BR2_PACKAGE_HAS_UDEV

[--SNIP--]
> diff --git a/package/libudev/libudev.mk b/package/libudev/libudev.mk
> new file mode 100644
> index 0000000..9dfd214
> --- /dev/null
> +++ b/package/libudev/libudev.mk
> @@ -0,0 +1,43 @@
> +################################################################################
> +#
> +# libudev
> +#
> +################################################################################
> +
> +LIBUDEV_VERSION = v1.6
> +LIBUDEV_SITE = $(call github,gentoo,eudev,$(LIBUDEV_VERSION))
> +LIBUDEV_LICENSE = GPLv2+ (programs), LGPLv2.1+ (libraries)
> +LIBUDEV_LICENSE_FILES = COPYING

I was wondering if we could somehow keep this in sync with the eudev
package, to avoid duplicating the versions, so we can bump both in a
single change.

> +LIBUDEV_INSTALL_STAGING = YES
> +LIBUDEV_AUTORECONF = YES
> +
> +LIBUDEV_DEPENDENCIES = host-pkgconf
> +
> +LIBUDEV_CONF_OPT += \
> +	--disable-manpages \
> +	--with-rootlibdir=/lib \
> +	--libexecdir=/lib \
> +	--with-firmware-path=/lib/firmware \
> +	--disable-introspection \

Would it be possible to build the library with introspection?
That would require adding gobject-introspection, though...
But I'm not too fluent in udev itself, so I won;t complain! ;-)

> +	--disable-keymap \
> +	--disable-libkmod \
> +	--disable-modules \
> +	--disable-selinux \
> +	--disable-rule-generator \
> +	--disable-gtk-doc \
> +	--disable-gudev \
> +	--enable-split-usr
> +
> +define LIBUDEV_BUILD_CMDS
> +	$(TARGET_MAKE_ENV) $(MAKE) -C $(@D)/src/libudev
> +endef
> +
> +define LIBUDEV_INSTALL_STAGING_CMDS
> +	$(TARGET_MAKE_ENV) $(MAKE) -C $(@D)/src/libudev DESTDIR=$(STAGING_DIR) install
> +endef
> +
> +define LIBUDEV_INSTALL_TARGET_CMDS
> +	$(TARGET_MAKE_ENV) $(MAKE) -C $(@D)/src/libudev DESTDIR=$(TARGET_DIR) install
> +endef
> +
> +$(eval $(autotools-package))

Otherwise, looks good to me.

Regards,
Yann E. MORIN.

Bernd, All,

On 2014-05-27 06:46 +0200, Bernd Kuhls spake thusly:
> "Yann E. MORIN" <yann.morin.1998@free.fr> wrote in
> news:20140526211909.GA13529@free.fr: 
> 
> >> +     depends on !BR2_INIT_SYSTEMD
> >> +     depends on !BR2_PACKAGE_EUDEV
> > 
> > Maybe replace those two 'depends on' with simply:
> > 
> >     depends on !BR2_PACKAGE_HAS_UDEV
> 
> I think we need to distinguish between the need for a daemon managing /dev 
> and libudev. Currently a lot of packages depend on BR2_PACKAGE_HAS_UDEV 
> although libudev should be enough for them. For libcec & xbmc I can confirm 
> this for sure, I suppose this is also valid for mesa3d, maybe others.

Well, the concept behind this single "depends on !HAS_UDEV" is that
udev-providing packages surely install a libudev.so, no?

Thus, there is no point in building libudev if we already have a
udev-providing package. Unless I'm misled.

> Libcec, for example, needs a patch like this for configure.ac though:
> 
> -    REQUIRES="$REQUIRES udev"
> +    REQUIRES="$REQUIRES libudev"
> 
> As several packages (systemd, eudev, libudev) can provide libudev we should 
> add a new provider BR2_PACKAGE_HAS_LIBUDEV and let xbmc, libcec, mesa, ... 
> depend on it instead of BR2_PACKAGE_HAS_UDEV. With this change in place 
> adding your suggestion makes sense.
> 
> What do you think?

I'm not sure about adding a new virtual package 'HAS_LIBUDEV'...
Further thinking is needed...

> >> +LIBUDEV_VERSION = v1.6
> >> +LIBUDEV_SITE = $(call github,gentoo,eudev,$(LIBUDEV_VERSION))
> >> +LIBUDEV_LICENSE = GPLv2+ (programs), LGPLv2.1+ (libraries)
> >> +LIBUDEV_LICENSE_FILES = COPYING
> > 
> > I was wondering if we could somehow keep this in sync with the eudev
> > package, to avoid duplicating the versions, so we can bump both in a
> > single change.
> 
> My plan is to merge libudev to the eudev package, a bump patch for eudev 
> v1.6 was already posted by sagaert.

Yes, that would be nice.

> >> +     --disable-introspection \
> > 
> > Would it be possible to build the library with introspection?
> > That would require adding gobject-introspection, though...
> > But I'm not too fluent in udev itself, so I won;t complain! ;-)
> 
> I?ll have a look.

Just a random thought, no worry! ;-)

Regards,
Yann E. MORIN.

"Yann E. MORIN" <yann.morin.1998@free.fr> wrote in
news:20140527171915.GB3503@free.fr: 

> Bernd, All,
> 
> On 2014-05-27 06:46 +0200, Bernd Kuhls spake thusly:
>> I think we need to distinguish between the need for a daemon managing
>> /dev and libudev. Currently a lot of packages depend on
>> BR2_PACKAGE_HAS_UDEV although libudev should be enough for them. For
>> libcec & xbmc I can confirm this for sure, I suppose this is also valid
>> for mesa3d, maybe others. 
> 
> Well, the concept behind this single "depends on !HAS_UDEV" is that
> udev-providing packages surely install a libudev.so, no?
> 
> Thus, there is no point in building libudev if we already have a
> udev-providing package. Unless I'm misled.

Hi,

ok, so we stick to "depends on BR2_PACKAGE_HAS_UDEV", even if the eudev 
package only builds libudev, this is something I am working on atm. Mesa3d 
already links to this libudev, I have yet to conduct runtime testing.

My current approach is to create a new option BR2_PACKAGE_EUDEV_DAEMON, 
default y for backward-compatability, which builds the eudev package like it 
is possible now. Having this option disabled will only build libudev. I am 
not sure if this is the right way Kconfig-wise, any suggestions?

Also I would like to propose changing the comment "xy needs udev /dev 
management" to something more correct because libudev does not manage /dev, 
it only reads it.

If a package really needs an udev daemon its dependency should then be 
changed.

Regards, Bernd

Bernd, All,

On 2014-06-11 18:28 +0200, Bernd Kuhls spake thusly:
> "Yann E. MORIN" <yann.morin.1998@free.fr> wrote in
> news:20140527171915.GB3503@free.fr: 
> 
> > Bernd, All,
> > 
> > On 2014-05-27 06:46 +0200, Bernd Kuhls spake thusly:
> >> I think we need to distinguish between the need for a daemon managing
> >> /dev and libudev. Currently a lot of packages depend on
> >> BR2_PACKAGE_HAS_UDEV although libudev should be enough for them. For
> >> libcec & xbmc I can confirm this for sure, I suppose this is also valid
> >> for mesa3d, maybe others. 
> > 
> > Well, the concept behind this single "depends on !HAS_UDEV" is that
> > udev-providing packages surely install a libudev.so, no?
> > 
> > Thus, there is no point in building libudev if we already have a
> > udev-providing package. Unless I'm misled.
> 
> Hi,
> 
> ok, so we stick to "depends on BR2_PACKAGE_HAS_UDEV", even if the eudev 

No, it's the opposite: depends on ! BR2_PACKAGE_HAS_UDEV

I.e., do not present libudev in the menuconfig if we already have either
systemd or eudev.

But since we want your libudev package to be merged with the eudev
package, we'll have to come with some tricks...

> package only builds libudev, this is something I am working on atm. Mesa3d 
> already links to this libudev, I have yet to conduct runtime testing.
> 
> My current approach is to create a new option BR2_PACKAGE_EUDEV_DAEMON, 
> default y for backward-compatability, which builds the eudev package like it 
> is possible now. Having this option disabled will only build libudev. I am 
> not sure if this is the right way Kconfig-wise, any suggestions?

I'll have a look at it tonight (UTC+2).

> Also I would like to propose changing the comment "xy needs udev /dev 
> management" to something more correct because libudev does not manage /dev, 
> it only reads it.
> 
> If a package really needs an udev daemon its dependency should then be 
> changed.

Not sure. I think we should keep _HAS_UDEV as-is, to mean "has a udev
daemon", and had a new virtual package _HAS_LIBUDEV which means "has a
libudev, but maybe not a daemon", and have the virtual package udev be a
provider of libudev.

I'll see what I can come up with.

Regards,
Yann E. MORIN.