On Fri, 2021-07-16 at 10:12 +0200, Nicolas Dechesne wrote:

hey!

On Thu, Jul 15, 2021 at 3:56 PM Richard Purdie <richard.purdie@...> wrote:

b) Some of the packaging code (at the very least) needs rewriting as it accesses
   both RDEPENDS_${PN} and puts ${PN} in OVERRIDES and accesses RDEPENDS. I'm not
   sure what else may be assuming this works.

Ouch.. I never realized that! I like Mark's suggestion to convert that to variables. RDEPENDS is typically
used in users' layers, so that  way they wouldn't be impacted by an override syntax change.

I have to admit I'm leaning the other way, make this explicit and hope that
it actually helps users understand overrides a little better by making it clear.

This change does buy us cleaner looking metadata and ultimately, a faster
and cleaner internal bitbake that at least would use less memory. It could set
the stage to allow the defval idea I mentioned in a previous mail to happen.

It is a huge change and would need a lot of work to make it happen. Is it worth 
doing? Not sure. I'm putting it out there for discussion.

There is no doubt that the change is a good change and the project would benefit 
from it. However I think we must worry about our users, and even look beyond the 
layer maintainers that we know (e.g. the one on this list). There are *way* more 
layer maintainers that we don't know about in all the many companies who are 
successfully using YP to build their products. I am not worried about all the main 
layers at all, since we know all their maintainers, and we know they will understand 
why we make this change, and will make the effort to support it. But I am very 
worried about the hundreds (thousands??) of layer maintainers in all the companies 
using Yocto. 

So if we do anything, I would really prefer if we find a way to do it in a good way 
*for them* , not *for us*. which means finding a way to support a soft transition. 
And of course we need to align this change with our LTS release cycle. So perhaps 
we can figure out how to support both syntaxes for some time (from one LTS to the 
next?), even if supporting both is impacting the performance. Or we can have a layer 
flag that indicates if it uses the old or the new syntax? 

If we support both forms, firstly, few of the layers you're concerned about will 
change as it will break older compatibility and they have no incentive to do so.

As I mentioned in another reply, there is a way some backwards compatibility could
be added however I do worry about the horrible corner cases that may result in.

Secondly, supporting both means we can't take advantage of any benefits the change
brings to further improve for a period of time. Do we want to commit to making this
change so that we can benefit from it in say four years time (a couple of LTS cycles 
you mention)?

I'm worried about the pain of transitioning, but I'm also very worried that unless
we figure out how we can change something, we're not going to develop beyond where
we are now.

I'm trying hard to find any way we can move forward with some of the issues people
are raising and I'm not seeing many options. I'm not seeing any proposals from anyone
else either, probably as there is so much inertia to overcome to make any change :(.

Cheers,

Richard