On 5/27/14, 11:35, "Saul Wold" <s...@linux.intel.com> 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. -- Darren Hart Open Source Technology Center darren.h...@intel.com Intel Corporation -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core