[OE-core] [PATCH] busybox: Add a dependency on virtual/crypt

[Randy MacLeod]

On 08/27/2018 02:42 AM, Andrej Valek wrote:
> Did you find some final solution?

Since no one has replied, it seems that the answer is to omit the
virtual/crypt dependency.

> For me, we can make it enabled by default. Anyone could use custom
> defconfig in own layer.

Right.


I would be nice get the package update done since 1.27.x is
about a year old and M3 is yesterday/this week.
We can settle this potential dependency as a defect if someone
finds such a bug.

../Randy


> 
> Cheers,
> Andrej
> 
> On 08/20/18 23:28, Andre McCurdy wrote:
>> On Mon, Aug 20, 2018 at 2:03 PM, Peter Kjellerstedt
>> <peter.kjellerstedt at axis.com> wrote:
>>>> -----Original Message-----
>>>> From: Andre McCurdy <armccurdy at gmail.com>
>>>> Sent: den 20 augusti 2018 22:23
>>>> To: Khem Raj <raj.khem at gmail.com>
>>>> Cc: Richard Purdie <richard.purdie at linuxfoundation.org>; Peter
>>>> Kjellerstedt <peter.kjellerstedt at axis.com>; Patches and discussions
>>>> about the oe-core layer <openembedded-core at lists.openembedded.org>
>>>> Subject: Re: [OE-core] [PATCH] busybox: Add a dependency on
>>>> virtual/crypt
>>>>
>>>> On Mon, Aug 20, 2018 at 12:45 PM, Khem Raj <raj.khem at gmail.com> wrote:
>>>>> On Mon, Aug 20, 2018 at 2:45 AM Richard Purdie
>>>>> <richard.purdie at linuxfoundation.org> wrote:
>>>>>>
>>>>>> On Mon, 2018-08-20 at 04:46 +0200, Peter Kjellerstedt wrote:
>>>>>>> busybox needs crypt() if CONFIG_USE_BB_CRYPT is not defined.
>>>>>>>
>>>>>>> Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt at axis.com>
>>>>>>> ---
>>>>>>>   meta/recipes-core/busybox/busybox.inc | 3 ++-
>>>>>>>   1 file changed, 2 insertions(+), 1 deletion(-)
>>>>>>>
>>>>>>> diff --git a/meta/recipes-core/busybox/busybox.inc b/meta/recipes-
>>>>>>> core/busybox/busybox.inc
>>>>>>> index 8c6dbbaf9b..a8ba10d21c 100644
>>>>>>> --- a/meta/recipes-core/busybox/busybox.inc
>>>>>>> +++ b/meta/recipes-core/busybox/busybox.inc
>>>>>>> @@ -3,7 +3,8 @@ DESCRIPTION = "BusyBox combines tiny versions of
>>>> many
>>>>>>> common UNIX utilities into
>>>>>>>   HOMEPAGE = "http://www.busybox.net"
>>>>>>>   BUGTRACKER = "https://bugs.busybox.net/"
>>>>>>>
>>>>>>> -DEPENDS += "kern-tools-native"
>>>>>>> +# Depend on virtual/crypt in case CONFIG_USE_BB_CRYPT is not
>>>> defined
>>>>>>> +DEPENDS += "kern-tools-native virtual/crypt"
>>>>>>
>>>>>> I'm not a bug fan of adding dependencies which might not be needed.
>>>> How
>>>>>> common is CONFIG_USE_BB_CRYPT not being defined? I assume that isn't
>>>>>> our default config?
>>>>>
>>>>> yes perhaps it should be packageconfig
>>>>
>>>> Busybox doesn't use PACKAGECONFIG. Conditional configuration is
>>>> handled by adding / removing cfg fragments and testing whether SRC_URI
>>>> contains "foo.cfg" (and also parsing the final .config within tasks
>>>> such as do_install). Unfortunately that approach doesn't work so well
>>>> for conditional build dependencies...
>>>>
>>>> Our Busybox defconfig does enable CONFIG_USE_BB_CRYPT (and there's no
>>>> cfg fragment to disable it) so the virtual/crypt dependency isn't
>>>> needed in our default builds.
>>>
>>> In our case we have our own defconfig. I am not responsible for it, it is
>>> maintained by our busybox maintainer, and he has apparently decided that
>>> we don't want CONFIG_USE_BB_CRYPT enabled.
>>
>> Could you ask him about it? Maybe there's some advantage to it that isn't clear.
>>
>> The general OE approach is to use system libraries when possible so
>> using external libcrypt does actually align to that.
>>
>> Maybe we should use external libcrypt by default (with the option to
>> switch back to the built-in crypt functions via a cfg fragment)?
>>
>>> I can of course add the dependency via a bbappend, but having to do that
>>> seems wrong given how the rest of busybox is configured (with defconfig
>>> and cfg fragments) and where enabling some options that don't happen to
>>> be enabled in the OE-Core default configuration will then break the build.
>>>
>>>> Disabling busybox's internal crypt functions doesn't seem like a very
>>>> common thing to want to do.
>>>>
>>>> config USE_BB_CRYPT
>>>>      bool "Use internal crypt functions"
>>>>      default y
>>>>      help
>>>>        Busybox has internal DES and MD5 crypt functions.
>>>>        They produce results which are identical to corresponding
>>>>        standard C library functions.
>>>>
>>>>        If you leave this disabled, busybox will use the system's
>>>>        crypt functions. Most C libraries use large (~70k)
>>>>        static buffers there, and also combine them with more general
>>>>        DES encryption/decryption.
>>>>
>>>>        For busybox, having large static buffers is undesirable,
>>>>        especially on NOMMU machines. Busybox also doesn't need
>>>>        DES encryption/decryption and can do with smaller code.
>>>>
>>>>        If you enable this option, it will add about 4.8k of code
>>>>        if you are building dynamically linked executable.
>>>>        In static build, it makes code _smaller_ by about 1.2k,
>>>>        and likely many kilobytes less of bss.
>>>
>>> //Peter
>>>


-- 
# Randy MacLeod
# Wind River Linux