* Can we drop eglibc-utils from LIBC_DEPENDENCIES?
@ 2011-12-16 18:30 Darren Hart
2011-12-16 21:07 ` Koen Kooi
0 siblings, 1 reply; 6+ messages in thread
From: Darren Hart @ 2011-12-16 18:30 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
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?
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: Can we drop eglibc-utils from LIBC_DEPENDENCIES? 2011-12-16 18:30 Can we drop eglibc-utils from LIBC_DEPENDENCIES? Darren Hart @ 2011-12-16 21:07 ` Koen Kooi 2011-12-16 23:20 ` Darren Hart 0 siblings, 1 reply; 6+ messages in thread From: Koen Kooi @ 2011-12-16 21:07 UTC (permalink / raw) To: Patches and discussions about the oe-core layer [-- Attachment #1: Type: text/plain, Size: 3925 bytes --] Op 16 dec. 2011, om 19:30 heeft Darren Hart het volgende geschreven: > 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, > 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? 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 [-- Attachment #2: Message signed with OpenPGP using GPGMail --] [-- Type: application/pgp-signature, Size: 169 bytes --] ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Can we drop eglibc-utils from LIBC_DEPENDENCIES? 2011-12-16 21:07 ` Koen Kooi @ 2011-12-16 23:20 ` Darren Hart 2011-12-16 23:34 ` Darren Hart 0 siblings, 1 reply; 6+ messages in thread From: Darren Hart @ 2011-12-16 23:20 UTC (permalink / raw) To: Patches and discussions about the oe-core layer; +Cc: Koen Kooi On 12/16/2011 01:07 PM, Koen Kooi wrote: > > Op 16 dec. 2011, om 19:30 heeft Darren Hart het volgende geschreven: > >> 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. >> 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? > > 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. Well, nfs isn't SDK only, there are valid deployment uses for that. But otherwise, agreed. > > 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? > > 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. > 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... -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Can we drop eglibc-utils from LIBC_DEPENDENCIES? 2011-12-16 23:20 ` Darren Hart @ 2011-12-16 23:34 ` Darren Hart 2011-12-17 1:29 ` Richard Purdie 0 siblings, 1 reply; 6+ messages in thread From: Darren Hart @ 2011-12-16 23:34 UTC (permalink / raw) To: Patches and discussions about the oe-core layer; +Cc: Koen Kooi On 12/16/2011 03:20 PM, Darren Hart wrote: > > > On 12/16/2011 01:07 PM, Koen Kooi wrote: >> >> Op 16 dec. 2011, om 19:30 heeft Darren Hart het volgende geschreven: >> >>> 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. > > >>> 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? >> >> 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. > > Well, nfs isn't SDK only, there are valid deployment uses for that. But > otherwise, agreed. > >> >> 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? > >> >> 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. > >> 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? -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Can we drop eglibc-utils from LIBC_DEPENDENCIES? 2011-12-16 23:34 ` Darren Hart @ 2011-12-17 1:29 ` Richard Purdie 2011-12-17 2:37 ` Darren Hart 0 siblings, 1 reply; 6+ messages in thread From: Richard Purdie @ 2011-12-17 1:29 UTC (permalink / raw) To: Patches and discussions about the oe-core layer; +Cc: Koen Kooi On Fri, 2011-12-16 at 15:34 -0800, Darren Hart wrote: > > On 12/16/2011 03:20 PM, Darren Hart wrote: > > > > > > On 12/16/2011 01:07 PM, Koen Kooi wrote: > >> > >> Op 16 dec. 2011, om 19:30 heeft Darren Hart het volgende geschreven: > >> > >>> 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. > > > > > >>> 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? > >> > >> 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. > > > > Well, nfs isn't SDK only, there are valid deployment uses for that. But > > otherwise, agreed. > > > >> > >> 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? > > > >> > >> 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. > > > >> 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? 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Can we drop eglibc-utils from LIBC_DEPENDENCIES? 2011-12-17 1:29 ` Richard Purdie @ 2011-12-17 2:37 ` Darren Hart 0 siblings, 0 replies; 6+ messages in thread From: Darren Hart @ 2011-12-17 2:37 UTC (permalink / raw) To: Patches and discussions about the oe-core layer; +Cc: Koen Kooi On 12/16/2011 05:29 PM, Richard Purdie wrote: > On Fri, 2011-12-16 at 15:34 -0800, Darren Hart wrote: >> >> On 12/16/2011 03:20 PM, Darren Hart wrote: >>> >>> >>> On 12/16/2011 01:07 PM, Koen Kooi wrote: >>>> >>>> Op 16 dec. 2011, om 19:30 heeft Darren Hart het volgende geschreven: >>>> >>>>> 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. >>> >>> >>>>> 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? >>>> >>>> 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. >>> >>> Well, nfs isn't SDK only, there are valid deployment uses for that. But >>> otherwise, agreed. >>> >>>> >>>> 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? >>> >>>> >>>> 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. >>> >>>> 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? > > 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. 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)} -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-12-17 2:44 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-12-16 18:30 Can we drop eglibc-utils from LIBC_DEPENDENCIES? Darren Hart 2011-12-16 21:07 ` Koen Kooi 2011-12-16 23:20 ` Darren Hart 2011-12-16 23:34 ` Darren Hart 2011-12-17 1:29 ` Richard Purdie 2011-12-17 2:37 ` Darren Hart
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox