[PATCH v4 1/4] tools: Separate image types which depend on OpenSSL

[Matthias Brugger]

On 22/10/2021 17:09, Tom Rini wrote:
> On Fri, Oct 22, 2021 at 04:59:22PM +0200, Marek Behún wrote:
>> On Fri, 22 Oct 2021 12:09:19 +0200
>> Heinrich Schuchardt <heinrich.schuchardt at canonical.com> wrote:
>>
>>> On 10/21/21 15:00, Marek Behún wrote:
>>>> BTW, wouldn't it be enough to simply imply TOOLS_LIBCRYPTO for mvebu
>>>> platform in Kconfig?
>>>>    
>>>
>>> We should only use 'imply' for suggested settings and never for hard
>>> requirements. TOOLS_LIBCRYPTO already defaults to 'Y'. So implying it
>>> for mvebu would be redundant.
>>>
>>> In an OS distribution we only want to ship a single version of mkimage.
>>> So it is good to elimate symbol CONFIG_MXS.
>>>
>>> How mkimage is built should not depend on CONFIG_TOOLS_LIBCRYPTO.
>>>
>>> Tom wrote regarding this aspect in
>>> https://lists.denx.de/pipermail/u-boot/2021-September/460251.html:
>>>
>>> "if we're building a generically useful tool, we don't want another
>>> symbol for it."
>>
>> OK, so mkimage and dumpimage should be always generic and always
>> support all platforms, that makes sense, since the tools can be
>> installed as a distribution package.
>>
>> But I still think it should be possible to cripple these tools if the
>> developer wants to disable libcrypto due to embedded environment.
> 
> This is probably the time to reach out to some of the distro folks to
> see how they would like to see things handled for "build the tools we
> need to package for the user" and also "build the binary for the
> platform".
> 

in openSUSE we are building the tools for each u-boot binary but those are not 
part of our u-boot-tools package. For that package we use sandbox_defconfig to 
only build the tools. So we are using openSSL in our packaging. AFAIK that's not 
an issue for us.

Regards,
Matthias