On Fri, 2021-07-16 at 10:12 +0200, Nicolas Dechesne wrote: > hey! > > On Thu, Jul 15, 2021 at 3:56 PM Richard Purdie > <[email protected]> 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
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1268): https://lists.openembedded.org/g/openembedded-architecture/message/1268 Mute This Topic: https://lists.openembedded.org/mt/84225642/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-architecture/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
