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

[Andrej Valek]

Did you find some final solution?
For me, we can make it enabled by default. Anyone could use custom
defconfig in own layer.

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
>>