Now that the package infrastructure doesn't attempt to download a package
that has an empty version string, there's no need to define the VERSION and
SOURCE variables in the getent package.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
External toolchains don't always install the executable in /usr/bin -
God knows why. So check in a few more places.
We can use make's $(wildcard ...) here, because the variable only gets
expanded when the install step is executed, and by that time the
STAGING_DIR has already been installed.
Probably fixes most getent autobuilder errors, at least if fixes
http://autobuild.buildroot.net/results/615b9d17f713b4a53192efb00188560a76b9efa3/
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The ecryptfs-utils scripts require the 'getent' program to be
installed to find the home directory of users. However, Buildroot
currently never installs this program, and therefore bug #7142 was
reported, explaining that ecryptfs-utils is not working properly.
In normal Linux systems, the getent program is provided by glibc, and
allows to query not only /etc/passwd, but also other NSS databases
such as LDAP and others.
In the context of Buildroot, this gives us several cases:
1/ Internal toolchain
a/ glibc/eglibc. In this case, the getent program is already built
and installed by Buildroot in the staging directory, so the
only thing missing is installing it in the target directory.
b/ uclibc. uClibc provides a simple shell script that emulates the
behavior of getent. It is located in extra/scripts/getent in
the uClibc sources, but is currently never installed.
c/ musl. There seems to be no getent implementation, and musl does
not support NSS.
2/ External toolchain
a/ glibc/eglibc. In several external toolchains that we tested,
there is a pre-built getent binary available in the sysroot,
but Buildroot is not installing it to the target.
b/ uclibc. The getent wrapper script is typically not part of any
external uClibc toolchain.
c/ musl. There is no getent implementation.
This patch proposes to solve this problem by introducing a getent
package, which has the following behavior:
- When the toolchain is glibc based (either internal or external), it
installs the getent program that was built and installed in the
staging directory. This covers cases 1/ a/ and 2/ a/ above.
- When the toolchain is uclibc or musl based, it installs a version
of uclibc's getent wrapper script that is built into the getent
package. This script is unlikely to change over time, so having it
directly built into the package should not cause much issues moving
forward. This covers all other cases above.
This solution allows to install a NSS-capable getent when glibc/eglibc
is used, and otherwise to rely on uClibc's wrapper script.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
