On Thu, 2017-12-07 at 11:08 -0600, Marcelo E. Magallon wrote: --snip!-- > My concern right now is a *different* case, where your goal is to modify > the class in order to affect all the recipes already inheriting from it. > For example, where there's a modification to a function in the class. > > Is there a good example out there as to how to implement such a thing?
In my case I needed to override behaviour of RPMs being installed on the target. We would download all files, reboot, run the RPM transaction during startup, then reboot again. The default behaviour to stop and restart services while upgrading the RPM packages was incompatible with our scheme (since we run the transaction with the services offline and then reboot into a new startup sequence anyway). So I cloned the update-rc.d.bbclass and commented a few lines out to not stop and restart the services, and placed this in our layer. For this to properly work, make sure that your layer priorities (and/or ordering) gives priority to your layer. Using this approach means you have to repeat this mod whenever you upgrade to a newer Yocto version (merge/carry forward your change to the new one then pop that in place of your old one). Regards, Darcy Darcy Watkins :: Senior Staff Engineer, Firmware SIERRA WIRELESS Direct +1 604 233 7989 :: Fax +1 604 231 1109 :: Main + 1 604 231 1100 13811 Wireless Way :: Richmond, BC Canada V6V 3A4 [P1] dwa tk...@sierrawireless.com :: www.sierrawireless.com -- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
