Actually, that's not bad either. As long as the magic is documented, that sounds pretty good too.
Steve On Tue, May 27, 2014 at 1:44 PM, Christopher Larson <[email protected]>wrote: > > 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 > >
-- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
