[yocto] Custom conf files

[Patrick Ohly]

On Tue, 2017-04-04 at 10:23 +0200, Jaap de Jong wrote:
> Hi,
> 
> I'm just wondering what the best practise is for configuration files 
> that I want to change for a specific image.
> 
> F.i. a simple one: /etc/issue

We just debated the exact same question over on the refkit mailing list,
without a conclusion (so far):
https://lists.yoctoproject.org/pipermail/intel-iot-refkit/2017-March/000007.html

There were two different opinions:
     1. Move config files into their own packages, create alternative
        packages with a different configuration, then in image recipes
        choose which package to install. Before Yocto 2.3,
        update-alternatives had to be used for this, starting with 2.3
        it is a bit simpler because recipe-specific sysroots allow
        different recipes to create packages with the same file (but one
        still cannot do it in the same recipe).
     2. Apply per-image configuration changes during rootfs
        construction. This could be done by dropping in entire files,
        sed expressions, or applying patches.

Personally, I prefer the second approach because it seems simpler,
ideally based on patches. That would have the advantage that there's no
need to keep a copied config file in sync with what upstream is changing
in that same file (i.e. the "I just want to change this one option" use
case becomes easier).

The downside is that it only works in combination with a system update
mechanism that updates the entire OS based on the final rootfs and some
care is needed when allowing local modifications of those same
configuration files (but that's problematic either way).

> I could create a bbappend for the responsible recipe.

That would be a third approach. However, that doesn't scale when
considering that the recipe might have to be used in different ways, and
layers which do that tend to be hard to reuse.

>  Or I could add a 
> ROOTFS_POSTPROCESS_COMMAND and patch in my changes

Yep.

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.