[OE-core] Creating a machine specific recipe for config file
Christopher Larson
clarson at kergoth.com
Tue May 27 20:44:33 UTC 2014
On Tue, May 27, 2014 at 1:39 PM, Darren Hart <dvhart at linux.intel.com> wrote:
> On 5/27/14, 11:35, "Saul Wold" <sgw at 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.
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20140527/8e063c7a/attachment-0002.html>
More information about the Openembedded-core
mailing list