On Tue, May 27, 2014 at 1:39 PM, Darren Hart <[email protected]> wrote:
> On 5/27/14, 11:35, "Saul Wold" <[email protected]> wrote: > > > > >Folks, > > > >We have had an open enhancement in the form of bugzilla #4011 > >(https://bugzilla.yoctoproject.org/show_bug.cgi?id=4011). > > > >I am currently working on this and want to get some feedback regarding > >the design, the below list of config files would move to one recipe in > >recipes-bsp, which will reduce the number of .bbappends that a BSP > >writer might need to create in order to customize the configuration of > >the BSP. > > > >Overall, my proposal is to move all the BSP related config files into > >one recipe directory tree. Create a recipe that can have a package or > >packages that are RRECOMMENDS on. > > > >We have 2 choices on the packaging side: > > > >1) 1 Package to rule them all (conffiles) > > - RPROVIDES PN-conf > > - conffile.bbclass > > RRECOMMENDS = "${PN}-conf" > > # Can be overriden in recipe > > CONFFILES_conffiles ?= "${PN}.conf" > > - Will provide files not needed on final image, small > > amount of extra space used. > > > >2) 1 package / conf file (${PN}-conf) > > - exactly what's needed will be installed > > - no needs for additional RPROVIDES > > - More packaging overhead, package data might be bigger than actual > >contents! > > The status quo would suggest that Option 2 is more consistent with what > people expect of the build system. However, if we were to do this, one > might question why we should bother at all and not just leave it in the > hands of MACHINE-specific overrides for the packages we're configuring, as > is done today with alsa-state/asound.conf (for example). > > What was your idea here - to replace the MACHINE-specific config for these > packages - or to augment it with an optional mega-config package? > > I think it would help to provide a bit of background/motivation regarding > what exactly we're trying to accomplish with this. That would help me form > an opinion on 1 vs 2 anyway. A third option would be to create a class which examines a path or paths to a directory structure containing just the config files, and injects a custom function into PACKAGEFUNCS which overlays the bsp-specific default configs into the original packages, obeying BBPATH to reflect layer priorities. It'd essentially be the same as what's done today, just a possibly more convenient way to do it, from a BSP maintainer perspective, and wouldn't even be terribly complex, but it might be seen as too much magic :) -- Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics
-- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
