On Fri, Jul 16, 2021 at 10:12:57AM +0200, Nicolas Dechesne wrote: > hey! > > On Thu, Jul 15, 2021 at 3:56 PM Richard Purdie < > [email protected]> wrote: > > > Breaking things down a bit, one thing I keep running into with our current > > codebase and metadata is that overrides are not clear. In my previous > > email, > > the example was: > > > > do_configure_class-native > > > > A human can usually spot "class-native" is and "configure" or > > "configure_class-native" is not. Bitbake's parser struggles. It has huge > > internal lists including variables like x86_64 where it has to track > > whether "64" in an override. > > > > One way of fixing this is to be explicit about overrides and use a > > different > > separator. See an example patch below I made to the quilt recipe using ":" > > instead to see how it looks. Personally, I think this looks like an > > improvement. > > > > There are two challenges: > > > > a) The work of migration. Do we migrate piecemeal or with a flag day? I'm > > not > > sure piecemeal is even possible unfortunately. > > > > 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. > > > > 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?
I agree. I understand that this change would be needed to improve the metadata we currently have, but I would like to stress that such big change in syntax would be major PIA for some use cases. E.g. with meta-ros https://github.com/ros/meta-ros which currently has over 7000 recipes mostly generated from OSRF index by superflore https://github.com/ros-infrastructure/superflore (there are a lot of changes every few days). Currently the work-flow is to regenerate the recipes for dunfell and then migrate these changes to other branches as well. With different syntax used in future LTS we would either need to teach superflore to generate different syntax (but regenerate new recipes twice with different syntax - and the regeneration takes quite a while) or reliable script to migrate to new syntax (to generate with old syntax with superflore and then migrate to new syntax before "cherry-pick" to the next LTS branch). So this is just one example that for some use-cases this change won't be just one-time flag-day to migrate existing metadata, but ongoing PIA to support multiple OE releases (e.g. dunfell LTS at the same time as the next LTS). Similarly for projects which do development e.g. on dunfell branch, but maintain a master branch compatible with latest for others to use, now if they need to spend significant time to migrate changes from dunfell to master (with the same syntax simple git merge was often good enough without any conflicts). And last example could be meta-qt5 where the branches are usually compatible with wide range of OE releases and projects tend to mismatch them often (because they need specific version of Qt - e.g. due licensing changes in newest - while using different OE release - e.g. webOS OSE was using dunfell for all layers except meta-qt5 in warrior branch to get Qt 5.12 with just small meta-qt5-compat shim layer to make them compatible (recently migrated to meta-qt6 in https://github.com/webosose/build-webos/commit/057477b7d8d95fee5714a468ed43defe085360a2) With a new syntax I would need to update these older meta-qt5 branches with the new syntax (like warrior-new-syntax branch for projects in this situation - or even 5.12-new-syntax or <next-lts>-5.12 which could include all compatibility tweaks directly). And meta-qt6 will have similar issue as now it has LAYERSERIES_COMPAT_qt6-layer = "zeus dunfell gatesgarth hardknott" in https://code.qt.io/cgit/yocto/meta-qt6.git/tree/conf/layer.conf?h=6.2 but for future it will need 2 syntax variants. Regards,
signature.asc
Description: PGP signature
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#1267): https://lists.openembedded.org/g/openembedded-architecture/message/1267 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]] -=-=-=-=-=-=-=-=-=-=-=-
