[OE-core] [PATCH 1/1] glibc: re-package for libnss-db

[Randy MacLeod]

On 08/15/2018 10:02 AM, Richard Purdie wrote:
> On Wed, 2018-08-15 at 15:00 +0800, Chen Qi wrote:
>> From: Jackie Huang <jackie.huang at windriver.com>
>>
>> On other distros like ubuntu/centos, libnss-db usually provides:
>> - The libraries
>> - The Makefile to create database
>>    (in /var/db for centos, /var/lib/misc/ for ubuntu)
>> - The makedb command (it's in glibc-common for centos7)
>>
>> What we had is:
>> - The libraries are in glibc-extra-nss
>> - The Makefile is removed
>> - The makedb command is in glibc-utils (lack of dependency)
>>
>> So when glibc-extra-nss is installed but glibc-utils is not,
>> we see error like:
>> nscd[165]: 165 checking for monitored file `/var/db/group.db': No
>> such file or directory
>> nscd[165]: 165 checking for monitored file `/var/db/passwd.db': No
>> such file or directory
>>
>> And there is not an easy way to create these databases.
>>
>> To fix the issue:
>> - Re-package the libraries into libnss-db
>> - Don't remove the Makefile and add it in libnss-db
>> - Add RDEPENDS for libnss-db on glibc-utils and make
>>
>> Notes:
>> For external toolchain, an extra package 'libnss-db' need to be
>> provided
>> If replacing glibc from core.
>>
>> Signed-off-by: Jackie Huang <jackie.huang at windriver.com>
>> Signed-off-by: Chen Qi <Qi.Chen at windriver.com>
>> ---
>>   meta/recipes-core/glibc/glibc-package.inc | 5 +++--
>>   1 file changed, 3 insertions(+), 2 deletions(-)
> 
> This breaks on the autobuilder in oe-selftest:
> 
> 2018-08-15 13:09:15,551 - oe-selftest - INFO - ======================================================================


...

> NOTE: Resolving any missing task queue dependencies
> ERROR: Nothing RPROVIDES 'make' (but /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-oe-selftest/build/meta/recipes-core/glibc/glibc_2.28.bb RDEPENDS on or otherwise requires it)
> make was skipped: it has an incompatible license: GPLv3 & LGPLv2
> NOTE: Runtime target 'make' is unbuildable, removing...
> Missing or unbuildable dependency chain was: ['make']
> ERROR: Required build target 'selftest-ed' has no buildable providers.
> Missing or unbuildable dependency chain was: ['selftest-ed', 'virtual/libc', 'make']
> 
> Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
> 
> https://autobuilder.yocto.io/builders/nightly-oe-selftest/builds/1281/steps/Running%20oe-selftest/logs/stdio
> 
> We really don't want a make dependency in glibc :(

Switching from RDEPENDS to RSUGGESTS  seems like a
reasonable solution. The GPLv2 build would work but
libnss-db would fail unless meta-gplv2 were used to
get an old version of make.

One way to avoid needing make is to demand that the bdb
files are generated during the build. That would be nice
but it shouldn't be a requirement since it's not the
typical workflow and since the db will usually be dynamic.

History and more details below.

../Randy

To support on target generation of the bdb files that
libnss-db uses then we need to:
  - separate the libnss-db files into a libnss-db pkg
  - *suggest* a 'make' as described below:

Back in January, Jackie had replied to:
    [OE-core] [PATCH 0/2 v2] glibc: fixes for nscd and libnss-db

with:

> Sorry, I didn't noticed that make is gplv3. I change the dependency to
> RSUGGESTS and the test passed:
> 
> $ oe-selftest -r bbtests.BitbakeTests.test_non_gplv3
> ...
> 2018-01-16 21:46:22,540 - oe-selftest - INFO - oe-selftest - OK - All required tests passed

but of course that papers over the failure by allowing the build to
pass even though runtime needs to include make to be able to
rebuild the db(s). And of course libnss-db isn't even being tested yet
so once we add that to oeqa, the test will fail for GPLv2-only images
where meta-gplv2 isn't added to the list of layers. I'm fine with
such oeqa failing when meta-gplv2 isn't around.


Qi, if no one comes up with a better idea,
please test that as well as:
   $ oe-selftest -r bbtests.BitbakeTests.test_non_gplv3
so that Richard doesn't burn another build cycle on it.

This isn't urgent but it would be nice to resolve the
issue properly for M3 without driving Richard around the bend!

Thanks,
../Randy


> 
> Cheers,
> 
> Richard
> 


-- 
# Randy MacLeod
# Wind River Linux