[OE-core] [RFC - WIP v2 01/10] conf-files: New recipe to create single recipe for config files

[Otavio Salvador]

On Fri, Jun 13, 2014 at 5:06 AM, Richard Purdie
<richard.purdie at linuxfoundation.org> wrote:
> On Thu, 2014-06-12 at 10:57 -0300, Otavio Salvador wrote:
>> On Thu, Jun 12, 2014 at 2:56 AM, Saul Wold <sgw at linux.intel.com> wrote:
>> > This recipe will create 1 package for config files, we could optionally add
>> > a bbclass file to ensure consistency with RRECOMMENDS_ = =conf
>> >
>> > This is a work in progress, the do_install might even beable to automagically
>> > generated.  We don't want to create a bbclass for these since it will cause
>> > the actual recipe/packaging to become machine specific, using this recipe will
>> > ioslate that.
>> >
>> > [YOCTO #4011]
>> >
>> > Signed-off-by: Saul Wold <sgw at linux.intel.com>
>>
>> I think the configuration file, nowadays, already made those machine
>> specific in every BSP which has those overriden so I don't see why use
>> a single recipe to provide several configuration files.
>>
>> I think it will be confusing and this recipe will fast grow.
>
> There are a few good reasons to do this.
>
> Machine customisation is spread around a whole load of different recipes
> at the moment and its hard to obtain a good view of what files are
> available and which ones a BSP author may need to provide.
>
> Its rather ugly to have to provide and maintain multiple bbappend files
> with rather ugly syntax within them. Its also rather inefficient from a
> build process standpoint to have 15-20 recipes just packaging
> configuration files.
>
> The intent isn't to mandate *every* config file should be in this
> recipe, you will as now be able to add additional ones. Where we see the
> same files being added in many layers, adding something common and
> shared makes sense though.
>
> It should in some cases also allow the "core" recipe to stop being
> machine specific and shared, improving build efficiency. There is little
> point in a recipe becomming machine specific over a config file.
>
> So I'd consider this move a consolation which we can improve over time.
> For new users I'd suggest that one more common place for the majority of
> machine specific files would be more understandable too.

I understand and mostly agree. However I don't want to have a recipe
with 20 configuration files where I'd need just two.

So I think we'd need to have a way to 'enable/disable' each
configuration override. Does it makes sense?

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750