* 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.