All of lore.kernel.org
 help / color / mirror / Atom feed
* Custom conf files
@ 2017-04-04  8:23 Jaap de Jong
  2017-04-04  9:21 ` Patrick Ohly
  0 siblings, 1 reply; 2+ messages in thread
From: Jaap de Jong @ 2017-04-04  8:23 UTC (permalink / raw)
  To: yocto

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

I could create a bbappend for the responsible recipe. Or I could add a 
ROOTFS_POSTPROCESS_COMMAND and patch in my changes

Are there other options?

What is the best practice?

Thanks!
Jaap



^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Custom conf files
  2017-04-04  8:23 Custom conf files Jaap de Jong
@ 2017-04-04  9:21 ` Patrick Ohly
  0 siblings, 0 replies; 2+ messages in thread
From: Patrick Ohly @ 2017-04-04  9:21 UTC (permalink / raw)
  To: Jaap de Jong; +Cc: yocto

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.





^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2017-04-04  9:22 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-04-04  8:23 Custom conf files Jaap de Jong
2017-04-04  9:21 ` Patrick Ohly

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.