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

[Tom Rini <trini@konsulko.com>]

[-- Attachment #1: Type: text/plain, Size: 1507 bytes --]

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@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".

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]