summaryrefslogtreecommitdiffstats
path: root/package/getent
Commit message (Collapse)AuthorAgeFilesLines
* boot, package: use SPDX short identifier for LGPLv2.1/LGPLv2.1+Rahul Bedarkar2017-04-011-1/+1
| | | | | | | | | | | We want to use SPDX identifier for license string as much as possible. SPDX short identifier for LGPLv2.1/LGPLv2.1+ is LGPL-2.1/LGPL-2.1+. This change is done using following command. find . -name "*.mk" | xargs sed -ri '/LICENSE( )?[\+:]?=/s/LGPLv2.1(\+)?/LGPL-2.1\1/g' Signed-off-by: Rahul Bedarkar <rahulbedarkar89@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* getent: remove VERSION/SOURCEThomas Petazzoni2016-07-031-4/+0
| | | | | | | | | 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>
* getent: look for glibc's getent in more placesArnout Vandecappelle2014-10-161-1/+5
| | | | | | | | | | | | | | | 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>
* getent: new packageThomas Petazzoni2014-10-123-0/+81
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>
OpenPOWER on IntegriCloud