Commit Graph

4 Commits

Author SHA1 Message Date
Rahul Bedarkar
30a3e8d108 boot, package: use SPDX short identifier for LGPLv2.1/LGPLv2.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>
2017-04-01 15:18:10 +02:00
Thomas Petazzoni
5c772a3942 getent: remove VERSION/SOURCE
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>
2016-07-03 12:54:59 +02:00
Arnout Vandecappelle
7f971ecf72 getent: look for glibc's getent in more places
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>
2014-10-16 11:01:45 +02:00
Thomas Petazzoni
db4919bcac getent: new package
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>
2014-10-12 18:28:46 +02:00