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
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
