Re: [meta-arm] [PATCH] arm/optee: Upgrade from 3.14 to 3.16

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Thu, 2022-03-10 at 13:44 +0000, Ross Burton wrote:
> On Thu, 10 Mar 2022 at 01:05, Alejandro Hernandez Samaniego
> <alhe@linux.microsoft.com> wrote:
> > I agree with Denys's point here, I think its likely there's other cases just like
> > meta-ti, and we would be forcing a meta-oe and meta-python dependency on them, IMO
> > it would make sense to add a copy of python3-cryptography to meta-arm (especially since
> > there's been similar situations in the past) and in parallel try to make a case for
> > python3-cryptography to be moved from meta-python to OE-core.
> > 
> > Once (and if) we're successful we can delete the python3-cyrptography copy from meta-arm.
> > 
> > This seems reasonable.  Can you rework your series to add this?  Also,
> > we need to keep the older version of OPTEE for corstone1000 (for the
> > kirkstone release).  So, if you can keep that around in v2, it would
> > be appreciated.
> 
> Sorry for being late to this thread, I've been elbow-deep in Python
> packaging changes.
> 
> As Tim said, moving python3-cryptography to meta-arm isn't one recipe:
> it's two recipes and four or so classes.  This isn't a trivial
> operation and I'm against that.
> 
> Can the use of python3-cryptography be a PACKAGECONFIG that is
> disabled in optee out of the box, so machines which want to use it can
> turn it on and add the dependency?
> 
> A less-worse option would be to DYNAMIC_LAYERS the optee recipes, so
> they're only parsed if meta-python is around.
> 
> Long term we definitely need to move the crypto stack to oe-core.  I
> wonder if RP would be open to moving it now...

I'm wondering how many classes/recipes are involved but I'm open to the idea...

Cheers,

Richard