[OE-core] Creating a machine specific recipe for config file

[Stephen Arnold]

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 <clarson at kergoth.com>wrote:

>
> 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
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20140527/24ac505f/attachment-0002.html>