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

[Mark Hatle <mark.hatle@windriver.com>]

On 6/13/14, 10:40 AM, Richard Purdie wrote:
> On Fri, 2014-06-13 at 12:30 -0300, Otavio Salvador wrote:
>> On Fri, Jun 13, 2014 at 5:06 AM, Richard Purdie
>> <richard.purdie@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@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@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?
>
> I'd have thought our standard inheritance would apply so that if you
> didn't append a machine specific version, the default would be used?

That was my expectation as well.  We know a certain set of things -could-, and 
are commonly configured by a BSP.  So we have a configuration 'recipe' that can 
use either the default file (provided by the non-machine specific version), or 
the machine specific configuration as a replacement due to the package 
management system(s).

The inheritance mechanism should work that if you add a configuration it is 
enabled, otherwise it's not and the default version is used instead.  (That's 
what I thought the anonymous python is doing within the 1/10 patch.)

--Mark



> Cheers,
>
> Richard
>
>