Can we drop eglibc-utils from LIBC_DEPENDENCIES?

DISCUSSION Darren Hart 3 participants 6 messages Dec 16, 2011 – Dec 17, 2011

Share & tools

Darren Hart

author

2011-12-16 18:38 UTC #0 lore raw

I'm working on a minimal distro definition, and found that eglibc-utils pulls in bash (needed for tzconfig and xtrace apparently) which pulls in gettext, which requires wchar support. I'd like to remove eglibc-utils from my distro definition. I could override the default I suspect, but I wonder if eglibc-utils should be made an optional package that distro definitions, images, or users should specifically add if needed?

The relevant bit of code appears to be:

meta/conf/distro/include/tclibc-eglibc.inc

LIBC_DEPENDENCIES = "libsegfault \
		     eglibc \
    		     eglibc-dbg \
    		     eglibc-dev \
    		     eglibc-utils \
    		     eglibc-thread-db \
    		     eglibc-localedata-i18n \
    		     eglibc-gconv-ibm850 \
    		     eglibc-gconv-cp1252 \
    		     eglibc-gconv-iso8859-1 \
    		     eglibc-gconv-iso8859-15 \
    		     locale-base-en-us \
    		     locale-base-en-gb "

eglibc-dbg and eglibc-dev also seem like they could be made optional.

Thoughts? Would anyone object to me removing at least eglibc-utils from LIBC_DEPENDENCIES?

Signature · 3 lines

Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

Koen Kooi

2011-12-16 21:14 UTC #1 lore raw

Op 16 dec. 2011, om 19:30 heeft Darren Hart het volgende geschreven:

Quoted 2 lines

I'm working on a minimal distro definition, and found that eglibc-utils pulls in bash (needed for tzconfig and xtrace apparently)

My first thought is: fix the bashisms in those scripts, I bet ubuntu/fedora/arch/gentoo have patches for that,

Quoted 24 lines

which pulls in
gettext, which requires wchar support. I'd like to remove eglibc-utils from my distro definition. I could override the default I suspect, but I wonder if eglibc-utils should be made an optional package that distro definitions, images, or users should specifically add if needed?
The relevant bit of code appears to be:
meta/conf/distro/include/tclibc-eglibc.inc
LIBC_DEPENDENCIES = "libsegfault \
		     eglibc \
   		     eglibc-dbg \
   		     eglibc-dev \
   		     eglibc-utils \
   		     eglibc-thread-db \
   		     eglibc-localedata-i18n \
   		     eglibc-gconv-ibm850 \
   		     eglibc-gconv-cp1252 \
   		     eglibc-gconv-iso8859-1 \
   		     eglibc-gconv-iso8859-15 \
   		     locale-base-en-us \
   		     locale-base-en-gb "

Quoted 4 lines

eglibc-dbg and eglibc-dev also seem like they could be made optional.
Thoughts? Would anyone object to me removing at least eglibc-utils from LIBC_DEPENDENCIES?

I did a little digging:

koen@dominion:/OE/tentacle/sources/openembedded-core$ git grep LIBC_DEPENDENCIES
meta/conf/distro/include/tclibc-eglibc.inc:LIBC_DEPENDENCIES = "libsegfault \
meta/conf/distro/include/tclibc-uclibc.inc:LIBC_DEPENDENCIES = "\
meta/recipes-core/tasks/task-core-nfs.bb:GLIBC_DEPENDENCIES = "glibc-utils"
meta/recipes-core/tasks/task-core-nfs.bb:RRECOMMENDS_task-core-nfs-server_append_libc-glibc = " ${GLIBC_DEPENDENCIES}"
meta/recipes-core/tasks/task-core-standalone-sdk-target.bb:    ${LIBC_DEPENDENCIES} \

So it's only used for debug and/or SDK uses. I am going to argue that if you're going to support debug and SDK you're not minimal anymore and can live with bash/gettext/etc.

Since I was bored I dug up an OE-classic:

koen@dominion:/OE/org.openembedded.dev$ git blame  recipes/tasks/task-sdk-bare.bb
749310c7 packages/tasks/task-sdk-bare.bb (Koen Kooi 2008-07-07 21:24:38 +0000  1) DESCRIPTION = "Packages for a standalone  SDK or external toolchain"
[..]
9bff47f7 packages/tasks/task-sdk-bare.bb (Tom Rini  2008-11-26 13:16:21 -0500  8) GLIBC_PKGS = "\
749310c7 packages/tasks/task-sdk-bare.bb (Koen Kooi 2008-07-07 21:24:38 +0000  9)     glibc \
749310c7 packages/tasks/task-sdk-bare.bb (Koen Kooi 2008-07-07 21:24:38 +0000 10)     glibc-dbg \
86fa8521 packages/tasks/task-sdk-bare.bb (Tom Rini  2009-02-04 02:07:47 -0500 11)     virtual-libc-dev \
749310c7 packages/tasks/task-sdk-bare.bb (Koen Kooi 2008-07-07 21:24:38 +0000 12)     glibc-utils \
749310c7 packages/tasks/task-sdk-bare.bb (Koen Kooi 2008-07-07 21:24:38 +0000 13)     libsegfault \
749310c7 packages/tasks/task-sdk-bare.bb (Koen Kooi 2008-07-07 21:24:38 +0000 14)     glibc-thread-db \
f18a05e2 recipes/tasks/task-sdk-bare.bb  (Tom Rini  2010-02-09 16:43:45 -0700 15) "
9bff47f7 packages/tasks/task-sdk-bare.bb (Tom Rini  2008-11-26 13:16:21 -0500 16) 
edd3a1de recipes/tasks/task-sdk-bare.bb  (Tom Rini  2011-01-18 17:56:52 -0700 17) LIBC_PKGS_libc-glibc = "${GLIBC_PKGS}"
edd3a1de recipes/tasks/task-sdk-bare.bb  (Tom Rini  2011-01-18 17:56:52 -0700 18) LIBC_PKGS_libc-uclibc = "uclibc uclibc-dev uclibc-thread-db"

So a few years ago that list of packages was only meant for SDK usage.

If you meant GLIBC_DEPENDENCIES (note the extra 'G'), then you need to check if they are still needed for NFS operation. If so I am going to argue that the dependencies should move to the recipes in question instead of hiding in the task. If it's just a convenience package go ahead and remove it, people wanting it can create a new task :)

regards,

Koen

Darren Hart

author

2011-12-16 23:27 UTC #2 lore raw

Quoted 7 lines · Koen Kooi

Op 16 dec. 2011, om 19:30 heeft Darren Hart het volgende geschreven:
Quoted 2 lines
I'm working on a minimal distro definition, and found that eglibc-utils pulls in bash (needed for tzconfig and xtrace apparently)
My first thought is: fix the bashisms in those scripts, I bet ubuntu/fedora/arch/gentoo have patches for that,

Agreed, this would be a good thing to do. However, I still shouldn't need to include this in a "tiny" distribution.

Quoted 31 lines

Quoted 24 lines
which pulls in
gettext, which requires wchar support. I'd like to remove eglibc-utils from my distro definition. I could override the default I suspect, but I wonder if eglibc-utils should be made an optional package that distro definitions, images, or users should specifically add if needed?
The relevant bit of code appears to be:
meta/conf/distro/include/tclibc-eglibc.inc
LIBC_DEPENDENCIES = "libsegfault \
		     eglibc \
   		     eglibc-dbg \
   		     eglibc-dev \
   		     eglibc-utils \
   		     eglibc-thread-db \
   		     eglibc-localedata-i18n \
   		     eglibc-gconv-ibm850 \
   		     eglibc-gconv-cp1252 \
   		     eglibc-gconv-iso8859-1 \
   		     eglibc-gconv-iso8859-15 \
   		     locale-base-en-us \
   		     locale-base-en-gb "
Quoted 4 lines
eglibc-dbg and eglibc-dev also seem like they could be made optional.
Thoughts? Would anyone object to me removing at least eglibc-utils from LIBC_DEPENDENCIES?
I did a little digging:

Quoted 8 lines

koen@dominion:/OE/tentacle/sources/openembedded-core$ git grep LIBC_DEPENDENCIES
meta/conf/distro/include/tclibc-eglibc.inc:LIBC_DEPENDENCIES = "libsegfault \
meta/conf/distro/include/tclibc-uclibc.inc:LIBC_DEPENDENCIES = "\
meta/recipes-core/tasks/task-core-nfs.bb:GLIBC_DEPENDENCIES = "glibc-utils"
meta/recipes-core/tasks/task-core-nfs.bb:RRECOMMENDS_task-core-nfs-server_append_libc-glibc = " ${GLIBC_DEPENDENCIES}"
meta/recipes-core/tasks/task-core-standalone-sdk-target.bb:    ${LIBC_DEPENDENCIES} \

So it's only used for debug and/or SDK uses. I am going to argue that if you're going to support debug and SDK you're not minimal anymore and can live with bash/gettext/etc.

Well, nfs isn't SDK only, there are valid deployment uses for that. But otherwise, agreed.

Quoted 17 lines

Since I was bored I dug up an OE-classic:

koen@dominion:/OE/org.openembedded.dev$ git blame  recipes/tasks/task-sdk-bare.bb
749310c7 packages/tasks/task-sdk-bare.bb (Koen Kooi 2008-07-07 21:24:38 +0000  1) DESCRIPTION = "Packages for a standalone  SDK or external toolchain"
[..]
9bff47f7 packages/tasks/task-sdk-bare.bb (Tom Rini  2008-11-26 13:16:21 -0500  8) GLIBC_PKGS = "\
749310c7 packages/tasks/task-sdk-bare.bb (Koen Kooi 2008-07-07 21:24:38 +0000  9)     glibc \
749310c7 packages/tasks/task-sdk-bare.bb (Koen Kooi 2008-07-07 21:24:38 +0000 10)     glibc-dbg \
86fa8521 packages/tasks/task-sdk-bare.bb (Tom Rini  2009-02-04 02:07:47 -0500 11)     virtual-libc-dev \
749310c7 packages/tasks/task-sdk-bare.bb (Koen Kooi 2008-07-07 21:24:38 +0000 12)     glibc-utils \
749310c7 packages/tasks/task-sdk-bare.bb (Koen Kooi 2008-07-07 21:24:38 +0000 13)     libsegfault \
749310c7 packages/tasks/task-sdk-bare.bb (Koen Kooi 2008-07-07 21:24:38 +0000 14)     glibc-thread-db \
f18a05e2 recipes/tasks/task-sdk-bare.bb  (Tom Rini  2010-02-09 16:43:45 -0700 15) "
9bff47f7 packages/tasks/task-sdk-bare.bb (Tom Rini  2008-11-26 13:16:21 -0500 16) 
edd3a1de recipes/tasks/task-sdk-bare.bb  (Tom Rini  2011-01-18 17:56:52 -0700 17) LIBC_PKGS_libc-glibc = "${GLIBC_PKGS}"
edd3a1de recipes/tasks/task-sdk-bare.bb  (Tom Rini  2011-01-18 17:56:52 -0700 18) LIBC_PKGS_libc-uclibc = "uclibc uclibc-dev uclibc-thread-db"

Was this list used in the same way as LIBC_DEPENDENCIES above?

Quoted 8 lines

So a few years ago that list of packages was only meant for SDK usage.
If you meant GLIBC_DEPENDENCIES (note the extra 'G'), then you need to
check if they are still needed for NFS operation. If so I am going to argue that the dependencies should move to the recipes in question instead of hiding in the task.

Right, that makes sense.

Quoted 2 lines

If it's just a convenience package go
ahead and remove it, people wanting it can create a new task :)

Agreed as well.

I ran into an interesting issue. If I remove eglibc-utils from LIBC_DEPENDENCIES, it still seems to be getting pulled in, as do bash and gettext. Still digging to sort out why...

Signature · 3 lines

Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

Darren Hart

author

2011-12-16 23:41 UTC #3 lore raw

Quoted 90 lines · Darren Hart

Quoted 7 lines · Koen Kooi
Op 16 dec. 2011, om 19:30 heeft Darren Hart het volgende geschreven:
Quoted 2 lines
I'm working on a minimal distro definition, and found that eglibc-utils pulls in bash (needed for tzconfig and xtrace apparently)
My first thought is: fix the bashisms in those scripts, I bet ubuntu/fedora/arch/gentoo have patches for that,
Agreed, this would be a good thing to do. However, I still shouldn't need to include this in a "tiny" distribution.
Quoted 31 lines
Quoted 24 lines
which pulls in
gettext, which requires wchar support. I'd like to remove eglibc-utils from my distro definition. I could override the default I suspect, but I wonder if eglibc-utils should be made an optional package that distro definitions, images, or users should specifically add if needed?
The relevant bit of code appears to be:
meta/conf/distro/include/tclibc-eglibc.inc
LIBC_DEPENDENCIES = "libsegfault \
		     eglibc \
   		     eglibc-dbg \
   		     eglibc-dev \
   		     eglibc-utils \
   		     eglibc-thread-db \
   		     eglibc-localedata-i18n \
   		     eglibc-gconv-ibm850 \
   		     eglibc-gconv-cp1252 \
   		     eglibc-gconv-iso8859-1 \
   		     eglibc-gconv-iso8859-15 \
   		     locale-base-en-us \
   		     locale-base-en-gb "
Quoted 4 lines
eglibc-dbg and eglibc-dev also seem like they could be made optional.
Thoughts? Would anyone object to me removing at least eglibc-utils from LIBC_DEPENDENCIES?
I did a little digging:
Quoted 8 lines
koen@dominion:/OE/tentacle/sources/openembedded-core$ git grep LIBC_DEPENDENCIES
meta/conf/distro/include/tclibc-eglibc.inc:LIBC_DEPENDENCIES = "libsegfault \
meta/conf/distro/include/tclibc-uclibc.inc:LIBC_DEPENDENCIES = "\
meta/recipes-core/tasks/task-core-nfs.bb:GLIBC_DEPENDENCIES = "glibc-utils"
meta/recipes-core/tasks/task-core-nfs.bb:RRECOMMENDS_task-core-nfs-server_append_libc-glibc = " ${GLIBC_DEPENDENCIES}"
meta/recipes-core/tasks/task-core-standalone-sdk-target.bb:    ${LIBC_DEPENDENCIES} \
So it's only used for debug and/or SDK uses. I am going to argue that if you're going to support debug and SDK you're not minimal anymore and can live with bash/gettext/etc.
Well, nfs isn't SDK only, there are valid deployment uses for that. But otherwise, agreed.
Quoted 17 lines
Since I was bored I dug up an OE-classic:
koen@dominion:/OE/org.openembedded.dev$ git blame  recipes/tasks/task-sdk-bare.bb
749310c7 packages/tasks/task-sdk-bare.bb (Koen Kooi 2008-07-07 21:24:38 +0000  1) DESCRIPTION = "Packages for a standalone  SDK or external toolchain"
[..]
9bff47f7 packages/tasks/task-sdk-bare.bb (Tom Rini  2008-11-26 13:16:21 -0500  8) GLIBC_PKGS = "\
749310c7 packages/tasks/task-sdk-bare.bb (Koen Kooi 2008-07-07 21:24:38 +0000  9)     glibc \
749310c7 packages/tasks/task-sdk-bare.bb (Koen Kooi 2008-07-07 21:24:38 +0000 10)     glibc-dbg \
86fa8521 packages/tasks/task-sdk-bare.bb (Tom Rini  2009-02-04 02:07:47 -0500 11)     virtual-libc-dev \
749310c7 packages/tasks/task-sdk-bare.bb (Koen Kooi 2008-07-07 21:24:38 +0000 12)     glibc-utils \
749310c7 packages/tasks/task-sdk-bare.bb (Koen Kooi 2008-07-07 21:24:38 +0000 13)     libsegfault \
749310c7 packages/tasks/task-sdk-bare.bb (Koen Kooi 2008-07-07 21:24:38 +0000 14)     glibc-thread-db \
f18a05e2 recipes/tasks/task-sdk-bare.bb  (Tom Rini  2010-02-09 16:43:45 -0700 15) "
9bff47f7 packages/tasks/task-sdk-bare.bb (Tom Rini  2008-11-26 13:16:21 -0500 16) 
edd3a1de recipes/tasks/task-sdk-bare.bb  (Tom Rini  2011-01-18 17:56:52 -0700 17) LIBC_PKGS_libc-glibc = "${GLIBC_PKGS}"
edd3a1de recipes/tasks/task-sdk-bare.bb  (Tom Rini  2011-01-18 17:56:52 -0700 18) LIBC_PKGS_libc-uclibc = "uclibc uclibc-dev uclibc-thread-db"
Was this list used in the same way as LIBC_DEPENDENCIES above?
Quoted 8 lines
So a few years ago that list of packages was only meant for SDK usage.
If you meant GLIBC_DEPENDENCIES (note the extra 'G'), then you need to
check if they are still needed for NFS operation. If so I am going to argue that the dependencies should move to the recipes in question instead of hiding in the task.
Right, that makes sense.

Quoted 8 lines

Quoted 2 lines
If it's just a convenience package go
ahead and remove it, people wanting it can create a new task :)
Agreed as well.
I ran into an interesting issue. If I remove eglibc-utils from LIBC_DEPENDENCIES, it still seems to be getting pulled in, as do bash and gettext. Still digging to sort out why...

It would appear that removing it from LIBC_DEPENDENCIES prevents it from being installed, but it is still built and, worse, so are all of it's RDEPENDS, which pull in bash and gettext and then break on a small libc with no widechar support.

So, is it correct behavior to build RDEPENDS for packages that will not be installed?

If so, I gather my fix is to remove eglibc-utils from the packages generated by the eglibc recipe when building with my tiny distro?

Signature · 3 lines

Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

Richard Purdie

2011-12-17 01:36 UTC #4 lore raw

Quoted 106 lines · Darren Hart

Quoted 90 lines · Darren Hart
Quoted 7 lines · Koen Kooi
Op 16 dec. 2011, om 19:30 heeft Darren Hart het volgende geschreven:
Quoted 2 lines
I'm working on a minimal distro definition, and found that eglibc-utils pulls in bash (needed for tzconfig and xtrace apparently)
My first thought is: fix the bashisms in those scripts, I bet ubuntu/fedora/arch/gentoo have patches for that,
Agreed, this would be a good thing to do. However, I still shouldn't need to include this in a "tiny" distribution.
Quoted 31 lines
Quoted 24 lines
which pulls in
gettext, which requires wchar support. I'd like to remove eglibc-utils from my distro definition. I could override the default I suspect, but I wonder if eglibc-utils should be made an optional package that distro definitions, images, or users should specifically add if needed?
The relevant bit of code appears to be:
meta/conf/distro/include/tclibc-eglibc.inc
LIBC_DEPENDENCIES = "libsegfault \
		     eglibc \
   		     eglibc-dbg \
   		     eglibc-dev \
   		     eglibc-utils \
   		     eglibc-thread-db \
   		     eglibc-localedata-i18n \
   		     eglibc-gconv-ibm850 \
   		     eglibc-gconv-cp1252 \
   		     eglibc-gconv-iso8859-1 \
   		     eglibc-gconv-iso8859-15 \
   		     locale-base-en-us \
   		     locale-base-en-gb "
Quoted 4 lines
eglibc-dbg and eglibc-dev also seem like they could be made optional.
Thoughts? Would anyone object to me removing at least eglibc-utils from LIBC_DEPENDENCIES?
I did a little digging:
Quoted 8 lines
koen@dominion:/OE/tentacle/sources/openembedded-core$ git grep LIBC_DEPENDENCIES
meta/conf/distro/include/tclibc-eglibc.inc:LIBC_DEPENDENCIES = "libsegfault \
meta/conf/distro/include/tclibc-uclibc.inc:LIBC_DEPENDENCIES = "\
meta/recipes-core/tasks/task-core-nfs.bb:GLIBC_DEPENDENCIES = "glibc-utils"
meta/recipes-core/tasks/task-core-nfs.bb:RRECOMMENDS_task-core-nfs-server_append_libc-glibc = " ${GLIBC_DEPENDENCIES}"
meta/recipes-core/tasks/task-core-standalone-sdk-target.bb:    ${LIBC_DEPENDENCIES} \
So it's only used for debug and/or SDK uses. I am going to argue that if you're going to support debug and SDK you're not minimal anymore and can live with bash/gettext/etc.
Well, nfs isn't SDK only, there are valid deployment uses for that. But otherwise, agreed.
Quoted 17 lines
Since I was bored I dug up an OE-classic:
koen@dominion:/OE/org.openembedded.dev$ git blame  recipes/tasks/task-sdk-bare.bb
749310c7 packages/tasks/task-sdk-bare.bb (Koen Kooi 2008-07-07 21:24:38 +0000  1) DESCRIPTION = "Packages for a standalone  SDK or external toolchain"
[..]
9bff47f7 packages/tasks/task-sdk-bare.bb (Tom Rini  2008-11-26 13:16:21 -0500  8) GLIBC_PKGS = "\
749310c7 packages/tasks/task-sdk-bare.bb (Koen Kooi 2008-07-07 21:24:38 +0000  9)     glibc \
749310c7 packages/tasks/task-sdk-bare.bb (Koen Kooi 2008-07-07 21:24:38 +0000 10)     glibc-dbg \
86fa8521 packages/tasks/task-sdk-bare.bb (Tom Rini  2009-02-04 02:07:47 -0500 11)     virtual-libc-dev \
749310c7 packages/tasks/task-sdk-bare.bb (Koen Kooi 2008-07-07 21:24:38 +0000 12)     glibc-utils \
749310c7 packages/tasks/task-sdk-bare.bb (Koen Kooi 2008-07-07 21:24:38 +0000 13)     libsegfault \
749310c7 packages/tasks/task-sdk-bare.bb (Koen Kooi 2008-07-07 21:24:38 +0000 14)     glibc-thread-db \
f18a05e2 recipes/tasks/task-sdk-bare.bb  (Tom Rini  2010-02-09 16:43:45 -0700 15) "
9bff47f7 packages/tasks/task-sdk-bare.bb (Tom Rini  2008-11-26 13:16:21 -0500 16) 
edd3a1de recipes/tasks/task-sdk-bare.bb  (Tom Rini  2011-01-18 17:56:52 -0700 17) LIBC_PKGS_libc-glibc = "${GLIBC_PKGS}"
edd3a1de recipes/tasks/task-sdk-bare.bb  (Tom Rini  2011-01-18 17:56:52 -0700 18) LIBC_PKGS_libc-uclibc = "uclibc uclibc-dev uclibc-thread-db"
Was this list used in the same way as LIBC_DEPENDENCIES above?
Quoted 8 lines
So a few years ago that list of packages was only meant for SDK usage.
If you meant GLIBC_DEPENDENCIES (note the extra 'G'), then you need to
check if they are still needed for NFS operation. If so I am going to argue that the dependencies should move to the recipes in question instead of hiding in the task.
Right, that makes sense.
Quoted 8 lines
Quoted 2 lines
If it's just a convenience package go
ahead and remove it, people wanting it can create a new task :)
Agreed as well.
I ran into an interesting issue. If I remove eglibc-utils from LIBC_DEPENDENCIES, it still seems to be getting pulled in, as do bash and gettext. Still digging to sort out why...
It would appear that removing it from LIBC_DEPENDENCIES prevents it from being installed, but it is still built and, worse, so are all of it's RDEPENDS, which pull in bash and gettext and then break on a small libc with no widechar support.

Quoted 5 lines

So, is it correct behavior to build RDEPENDS for packages that will not be installed?
If so, I gather my fix is to remove eglibc-utils from the packages generated by the eglibc recipe when building with my tiny distro?

What I suspect you're seeing is something like a recipe which does:

PACKAGES = "A B"
RDEPENDS_A = "1 2 3"
RDEPENDS_B = "2 3 4"

and that you're using A but not B. Since the build system needs to build A and B at the same time as they're part of the same recipe, it will build 1-4. It won't necessarily install them.

Usually, if this is causing conflict we'd split the recipe up.

Cheers,

Richard

Darren Hart

author

2011-12-17 02:44 UTC #5 lore raw

Quoted 119 lines · Richard Purdie

Quoted 106 lines · Darren Hart
Quoted 90 lines · Darren Hart
Quoted 7 lines · Koen Kooi
Op 16 dec. 2011, om 19:30 heeft Darren Hart het volgende geschreven:
Quoted 2 lines
I'm working on a minimal distro definition, and found that eglibc-utils pulls in bash (needed for tzconfig and xtrace apparently)
My first thought is: fix the bashisms in those scripts, I bet ubuntu/fedora/arch/gentoo have patches for that,
Agreed, this would be a good thing to do. However, I still shouldn't need to include this in a "tiny" distribution.
Quoted 31 lines
Quoted 24 lines
which pulls in
gettext, which requires wchar support. I'd like to remove eglibc-utils from my distro definition. I could override the default I suspect, but I wonder if eglibc-utils should be made an optional package that distro definitions, images, or users should specifically add if needed?
The relevant bit of code appears to be:
meta/conf/distro/include/tclibc-eglibc.inc
LIBC_DEPENDENCIES = "libsegfault \
		     eglibc \
   		     eglibc-dbg \
   		     eglibc-dev \
   		     eglibc-utils \
   		     eglibc-thread-db \
   		     eglibc-localedata-i18n \
   		     eglibc-gconv-ibm850 \
   		     eglibc-gconv-cp1252 \
   		     eglibc-gconv-iso8859-1 \
   		     eglibc-gconv-iso8859-15 \
   		     locale-base-en-us \
   		     locale-base-en-gb "
Quoted 4 lines
eglibc-dbg and eglibc-dev also seem like they could be made optional.
Thoughts? Would anyone object to me removing at least eglibc-utils from LIBC_DEPENDENCIES?
I did a little digging:
Quoted 8 lines
koen@dominion:/OE/tentacle/sources/openembedded-core$ git grep LIBC_DEPENDENCIES
meta/conf/distro/include/tclibc-eglibc.inc:LIBC_DEPENDENCIES = "libsegfault \
meta/conf/distro/include/tclibc-uclibc.inc:LIBC_DEPENDENCIES = "\
meta/recipes-core/tasks/task-core-nfs.bb:GLIBC_DEPENDENCIES = "glibc-utils"
meta/recipes-core/tasks/task-core-nfs.bb:RRECOMMENDS_task-core-nfs-server_append_libc-glibc = " ${GLIBC_DEPENDENCIES}"
meta/recipes-core/tasks/task-core-standalone-sdk-target.bb:    ${LIBC_DEPENDENCIES} \
So it's only used for debug and/or SDK uses. I am going to argue that if you're going to support debug and SDK you're not minimal anymore and can live with bash/gettext/etc.
Well, nfs isn't SDK only, there are valid deployment uses for that. But otherwise, agreed.
Quoted 17 lines
Since I was bored I dug up an OE-classic:
koen@dominion:/OE/org.openembedded.dev$ git blame  recipes/tasks/task-sdk-bare.bb
749310c7 packages/tasks/task-sdk-bare.bb (Koen Kooi 2008-07-07 21:24:38 +0000  1) DESCRIPTION = "Packages for a standalone  SDK or external toolchain"
[..]
9bff47f7 packages/tasks/task-sdk-bare.bb (Tom Rini  2008-11-26 13:16:21 -0500  8) GLIBC_PKGS = "\
749310c7 packages/tasks/task-sdk-bare.bb (Koen Kooi 2008-07-07 21:24:38 +0000  9)     glibc \
749310c7 packages/tasks/task-sdk-bare.bb (Koen Kooi 2008-07-07 21:24:38 +0000 10)     glibc-dbg \
86fa8521 packages/tasks/task-sdk-bare.bb (Tom Rini  2009-02-04 02:07:47 -0500 11)     virtual-libc-dev \
749310c7 packages/tasks/task-sdk-bare.bb (Koen Kooi 2008-07-07 21:24:38 +0000 12)     glibc-utils \
749310c7 packages/tasks/task-sdk-bare.bb (Koen Kooi 2008-07-07 21:24:38 +0000 13)     libsegfault \
749310c7 packages/tasks/task-sdk-bare.bb (Koen Kooi 2008-07-07 21:24:38 +0000 14)     glibc-thread-db \
f18a05e2 recipes/tasks/task-sdk-bare.bb  (Tom Rini  2010-02-09 16:43:45 -0700 15) "
9bff47f7 packages/tasks/task-sdk-bare.bb (Tom Rini  2008-11-26 13:16:21 -0500 16) 
edd3a1de recipes/tasks/task-sdk-bare.bb  (Tom Rini  2011-01-18 17:56:52 -0700 17) LIBC_PKGS_libc-glibc = "${GLIBC_PKGS}"
edd3a1de recipes/tasks/task-sdk-bare.bb  (Tom Rini  2011-01-18 17:56:52 -0700 18) LIBC_PKGS_libc-uclibc = "uclibc uclibc-dev uclibc-thread-db"
Was this list used in the same way as LIBC_DEPENDENCIES above?
Quoted 8 lines
So a few years ago that list of packages was only meant for SDK usage.
If you meant GLIBC_DEPENDENCIES (note the extra 'G'), then you need to
check if they are still needed for NFS operation. If so I am going to argue that the dependencies should move to the recipes in question instead of hiding in the task.
Right, that makes sense.
Quoted 8 lines
Quoted 2 lines
If it's just a convenience package go
ahead and remove it, people wanting it can create a new task :)
Agreed as well.
I ran into an interesting issue. If I remove eglibc-utils from LIBC_DEPENDENCIES, it still seems to be getting pulled in, as do bash and gettext. Still digging to sort out why...
It would appear that removing it from LIBC_DEPENDENCIES prevents it from being installed, but it is still built and, worse, so are all of it's RDEPENDS, which pull in bash and gettext and then break on a small libc with no widechar support.
Quoted 5 lines
So, is it correct behavior to build RDEPENDS for packages that will not be installed?
If so, I gather my fix is to remove eglibc-utils from the packages generated by the eglibc recipe when building with my tiny distro?
What I suspect you're seeing is something like a recipe which does:
PACKAGES = "A B"
RDEPENDS_A = "1 2 3"
RDEPENDS_B = "2 3 4"

Quoted 5 lines

and that you're using A but not B. Since the build system needs to build A and B at the same time as they're part of the same recipe, it will build 1-4. It won't necessarily install them.
Usually, if this is causing conflict we'd split the recipe up.

I did the following to eglibc which seems to work:

-PACKAGES = "${PN}-dbg ${PN} catchsegv${PKGSUFFIX} sln${PKGSUFFIX} nscd${PKGSUFFIX} ldd${PKGSUFFIX} ${PN}-utils eglibc-extra-nss${PKGSU +PACKAGES = "${PN}-dbg ${PN} catchsegv${PKGSUFFIX} sln${PKGSUFFIX} nscd${PKGSUFFIX} ldd${PKGSUFFIX} eglibc-extra-nss${PKGSUFFIX} eglibc +
+# eglibc-utils rdepends on bash which depends on gettext which requires wchar
+# support. Only include it in the PACKAGES list if we can build the RDEPENDS.
+PACKAGES += ${@base_contains('DISTRO_FEATURES', 'libc-posix-clang-wchar', '${PN}-utils', '', d)}

Signature · 3 lines

Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel