<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 27, 2014 at 1:39 PM, Darren Hart <span dir="ltr"><<a href="mailto:dvhart@linux.intel.com" target="_blank">dvhart@linux.intel.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb adM"><div class="h5">On 5/27/14, 11:35, "Saul Wold" <<a href="mailto:sgw@linux.intel.com">sgw@linux.intel.com</a>> wrote:<br>
<br>
><br>
>Folks,<br>
><br>
>We have had an open enhancement in the form of bugzilla #4011<br>
>(<a href="https://bugzilla.yoctoproject.org/show_bug.cgi?id=4011" target="_blank">https://bugzilla.yoctoproject.org/show_bug.cgi?id=4011</a>).<br>
><br>
>I am currently working on this and want to get some feedback regarding<br>
>the design, the below list of config files would move to one recipe in<br>
>recipes-bsp, which will reduce the number of .bbappends that a BSP<br>
>writer might need to create in order to customize the configuration of<br>
>the BSP.<br>
><br>
>Overall, my proposal is to move all the BSP related config files into<br>
>one recipe directory tree. Create a recipe that can have a package or<br>
>packages that are RRECOMMENDS on.<br>
><br>
>We have 2 choices on the packaging side:<br>
><br>
>1) 1 Package to rule them all (conffiles)<br>
> - RPROVIDES PN-conf<br>
> - conffile.bbclass<br>
> RRECOMMENDS = "${PN}-conf"<br>
> # Can be overriden in recipe<br>
> CONFFILES_conffiles ?= "${PN}.conf"<br>
> - Will provide files not needed on final image, small<br>
> amount of extra space used.<br>
><br>
>2) 1 package / conf file (${PN}-conf)<br>
> - exactly what's needed will be installed<br>
> - no needs for additional RPROVIDES<br>
> - More packaging overhead, package data might be bigger than actual<br>
>contents!<br>
<br>
</div></div>The status quo would suggest that Option 2 is more consistent with what<br>
people expect of the build system. However, if we were to do this, one<br>
might question why we should bother at all and not just leave it in the<br>
hands of MACHINE-specific overrides for the packages we're configuring, as<br>
is done today with alsa-state/asound.conf (for example).<br>
<br>
What was your idea here - to replace the MACHINE-specific config for these<br>
packages - or to augment it with an optional mega-config package?<br>
<br>
I think it would help to provide a bit of background/motivation regarding<br>
what exactly we're trying to accomplish with this. That would help me form<br>
an opinion on 1 vs 2 anyway.</blockquote></div><br></div><div class="gmail_extra">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 :)<br>
</div><div class="gmail_extra">-- <br>Christopher Larson<br>clarson at kergoth dot com<br>Founder - BitBake, OpenEmbedded, OpenZaurus<br>Maintainer - Tslib<br>Senior Software Engineer, Mentor Graphics
</div></div>