[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] Managing etc/* in an embbeded system
From:       Zac Medico <zmedico () gentoo ! org>
Date:       2015-07-23 15:47:02
Message-ID: 55B10C76.2040709 () gentoo ! org
[Download RAW message or body]

On 07/23/2015 12:46 AM, Joakim Tjernlund wrote:
> On Wed, 2015-07-22 at 19:47 -0400, Ian Stakenvicius wrote:
> > 
> > Sent from an iPhone, sorry for the HTML...
> > 
> > > On Jul 22, 2015, at 5:38 PM, Rich Freeman <rich0@gentoo.org> wrote:
> > > 
> > > On Wed, Jul 22, 2015 at 8:05 AM, Joakim Tjernlund
> > > <joakim.tjernlund@transmode.se> wrote:
> > > > 
> > > > There can not be any manual merges after an SW update here.
> > > > 
> > > > I started to look at INSTALL_MASK, what if I set INSTALL_MASK
> > > > to point to all conf files I want to manage myself.
> > > > Then /etc/inittab etc. will not be touched when updating init
> > > 
> > > This sounds like overkill.
> > > 
> > > If you've already installed a custom /etc/inittab, then when you
> > > emerge init, it won't overwrite your inittab even if you don't change
> > > anything in your portage config.  emerge won't touch any files in /etc
> > > unless they don't already exist.  
> > 
> > 
> > ..AND have been modified.  IIRC if the hash of the config files match what they \
> > were when the package was  previously emerged, then the files are updated aren't \
> > they? 
> > I expect that this is fine in the situation described, but it's worth knowing \
> > that a config file left  unmodified may be replaced with a different vanilla \
> > config file later on.
> 
> Sure, but what if I need to change a conf file in an installed system? Or rebuild a \
> a system from scratch? The user only runs a one SW update command to update an \
> installed system in the field and cannot edit a bunch of files too. Especially when \
> there are hundreds of systems sitting in remote locations.

If you use the profile-bashrcs profile-formats setting [1], then your
profiles can use package.bashrc to define post_src_install and/or
INSTALL_MASK to remove unwanted config files from upstream packages.
Then you can easily replace the upstream config files with config files
installed by your own configurations installed by your own ebuilds.

> This is why I need a way change conf files automatically and I want to use \
> ebuilds/profile as far as possible. I think there is room for some improvement here \
> in portage to allow this kind of customization.

A template engine such as jinja [2] can be use to automate rendering of
your config files with settings that are specific to a particular system.

[1]
https://gitweb.gentoo.org/proj/portage.git/commit/?id=803dafc462027d6015721f40513abb5f57dc1178
 [2] http://jinja.pocoo.org/
-- 
Thanks,
Zac


[prev in list] [next in list] [prev in thread] [next in thread]