On Fri, Jul 16, 2021 at 12:09 PM Richard Purdie < [email protected]> wrote:
> 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. > Well, I am not asking we support both forever, but that we offer a proper transition period. For most key (and public) layers, it might be an option to switch 'quickly' enough, but for developers involved in making projects they are lagging behind what the 'core' community is doing. So telling them in the next LTS everything breaks is not a very good message. > > 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. > I definitely understand that.. I am just trying to emphasize that it's important to think about the large user base that is out of our reach. > > 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 didn't not say a couple of LTS cycles ;) but from one LTS to the next. So perhaps a 2 year transition period. e.g. introduce the change in the next LTS, and deprecate the old syntax in the next-next LTS. > > 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 (#1269): https://lists.openembedded.org/g/openembedded-architecture/message/1269 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]] -=-=-=-=-=-=-=-=-=-=-=-
