Re: Creating a machine specific recipe for config file

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

On 5/27/14, 3:39 PM, Darren Hart wrote:
> On 5/27/14, 11:35, "Saul Wold" <sgw@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?

The reason to get away from MACHINE-specific config changes to the regular 
package is from a re-use standpoint.

If BSP_A and BSP_B both need different configurations of the FOO recipe, the 
"right" way today is for two machine specific versions of the FOO recipe/package 
to be generated.

foo-ver-rel.BSP_A.rpm
foo-ver-rel.BSP_B.rpm

This eliminates a lot of potential re-use, and if it's a large package could add 
a lot of unnecessary space (and build time) to the system.

Instead what we want is:

foo-ver-rel.armv7.rpm
foo-conf-ver-rel.armv7.rpm
foo-conf-ver-rel.BSP_A.rpm
foo-conf-ver-rel.BSP_B.rpm

So the package management system will select the best package to meet the 
requirement automatically.  You get to re-use the one foo package on all 
compatible system.  And then you can choose from a default (not-configured), or 
a BSP configuration.  Much quicker to package, install and takes (potentially) 
less space.  (On a trivial hello-world example, it'll actually take more space, 
but get outside the trivial and it will be helpful.)

> 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.

So when talking with Saul I suggested that we do either #1 or #2.. and the base 
recipe (not configure) had a require or recommend of the configure file.

The more I think about this, the more I think multiple small configuration 
files/packages makes sense.. due to various system configuration possibilities 
-- but using appropriate RPROVIDES we shouldn't prevent the system from allowing 
a single monolitic configuration for a BSP.

--Mark