[Buildroot] [PATCH v3 3/5] eudev: new package.
Thomas De Schampheleire
patrickdepinguin at gmail.com
Sun Nov 17 08:16:26 UTC 2013
Hi Thomas, all,
On Wed, Nov 13, 2013 at 11:41 PM, Thomas Petazzoni
<thomas.petazzoni at free-electrons.com> wrote:
>> +config BR2_PACKAGE_EUDEV
>> + bool "eudev"
>> + depends on BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_EUDEV
>> + depends on BR2_LARGEFILE # util-linux
>> + depends on BR2_USE_WCHAR # util-linux
>> + depends on !BR2_PACKAGE_SYSTEMD
>> + select BR2_PACKAGE_HAS_UDEV
>> + select BR2_PACKAGE_UTIL_LINUX
>> + select BR2_PACKAGE_UTIL_LINUX_LIBBLKID
>> + select BR2_PACKAGE_KMOD
>> + help
>> + Userspace device daemon. This is a standalone version,
>> + independent of systemd. It is a fork maintained by Gentoo.
> The indentation of this part of the help text is wrong. It should be
> one tab + two spaces. Also, this package has dependencies on toolchain
> options, so we usually have corresponding comments... but it's true
> that the package will anyway only be visible when
> BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_EUDEV, and you have added the
> comments where BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_EUDEV is defined.
> There is also a decision to be taken here: do we duplicate the
> dependencies here? If we don't duplicate the comments, then maybe we
> shouldn't duplicate the dependencies?
The advantage of duplicating the dependencies is that there is no room
for mistakes. The policy is clear.
Take the example where package A depends on B and B needs threads.
Strictly speaking, A does not need to repeat the dependency.
However, what if A also needs threads. This may or may not be known to
the author of that package (or anyone who touches its Config.in
files). If a new version of B appears that no longer depends on
threads and this dependency is removed from B/Config.in, the
dependency of A on threads will no longer be expressed. This is a
As making the difference between 'does the package itself also needs
this dependency' or 'only the package dependencies have this
dependency' is not obvious, having different rules in this matter
creates a difficult to maintain situation IMO. Therefore, I am more in
favor of duplicating the dependencies consistently, along with the
Other inputs are obviously very welcome.
More information about the buildroot