Gentoo Archives: gentoo-dev

From: Zac Medico <zmedico@g.o>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Managing etc/* in an embbeded system
Date: Tue, 11 Aug 2015 19:07:19
Message-Id: 55CA47D8.4020107@gentoo.org
In Reply to: Re: [gentoo-dev] Managing etc/* in an embbeded system by Joakim Tjernlund
1 On 08/11/2015 11:11 AM, Joakim Tjernlund wrote:
2 > On Tue, 2015-08-11 at 10:55 -0700, Zac Medico wrote:
3 >> On 08/11/2015 10:48 AM, Joakim Tjernlund wrote:
4 >>> On Thu, 2015-07-23 at 08:47 -0700, Zac Medico wrote:
5 >>>> On 07/23/2015 12:46 AM, Joakim Tjernlund wrote:
6 >>>>> On Wed, 2015-07-22 at 19:47 -0400, Ian Stakenvicius wrote:
7 >>>>>>
8 >>>>>> Sent from an iPhone, sorry for the HTML...
9 >>>>>>
10 >>>>>>> On Jul 22, 2015, at 5:38 PM, Rich Freeman <rich0@g.o> wrote:
11 >>>>>>>
12 >>>>>>> On Wed, Jul 22, 2015 at 8:05 AM, Joakim Tjernlund
13 >>>>>>> <joakim.tjernlund@×××××××××.se> wrote:
14 >>>>>>>>
15 >>>>>>>> There can not be any manual merges after an SW update here.
16 >>>>>>>>
17 >>>>>>>> I started to look at INSTALL_MASK, what if I set INSTALL_MASK
18 >>>>>>>> to point to all conf files I want to manage myself.
19 >>>>>>>> Then /etc/inittab etc. will not be touched when updating init
20 >>>>>>>
21 >>>>>>> This sounds like overkill.
22 >>>>>>>
23 >>>>>>> If you've already installed a custom /etc/inittab, then when you
24 >>>>>>> emerge init, it won't overwrite your inittab even if you don't change
25 >>>>>>> anything in your portage config. emerge won't touch any files in /etc
26 >>>>>>> unless they don't already exist.
27 >>>>>>
28 >>>>>>
29 >>>>>> ..AND have been modified. IIRC if the hash of the config files match what they were when the
30 >>>>>> package
31 >>>>>> was
32 >>>>>> previously emerged, then the files are updated aren't they?
33 >>>>>>
34 >>>>>> I expect that this is fine in the situation described, but it's worth knowing that a config file
35 >>>>>> left
36 >>>>>> unmodified may be replaced with a different vanilla config file later on.
37 >>>>>
38 >>>>> Sure, but what if I need to change a conf file in an installed system? Or rebuild a a system from
39 >>>>> scratch?
40 >>>>> The user only runs a one SW update command to update an installed system in the field and cannot edit
41 >>>>> a
42 >>>>> bunch
43 >>>>> of files too. Especially when there are hundreds of systems sitting in remote locations.
44 >>>>
45 >>>> If you use the profile-bashrcs profile-formats setting [1], then your
46 >>>> profiles can use package.bashrc to define post_src_install and/or
47 >>>> INSTALL_MASK to remove unwanted config files from upstream packages.
48 >>>> Then you can easily replace the upstream config files with config files
49 >>>> installed by your own configurations installed by your own ebuilds.
50 >>>
51 >>> Finally getting back to this after lots of distractions.
52 >>> I cannot get profile-formats = profile-bashrcs to work.
53 >>> I have in metadata/layout.conf:
54 >>> masters = gentoo
55 >>> profile-formats = portage-2 profile-bashrcs
56 >>> then in profiles/tmv3-target-overlay/profile.bashrc:
57 >>> INSTALL_MASK=xxxx
58 >>> Doing portageq envvar INSTALL_MASK just yields an empty line
59 >>> I guess I am missing something here?
60 >>>
61 >>>
62 >>
63 >> See the "man portage" for profile-bashrcs details. It uses
64 >> package.bashrc rather than profile.bashrc, so that explains why it's not
65 >> working for you.
66 >
67 > hmm, I figured I could use profile.bashrc to set stuff for all pkgs?
68
69 You can, but package.bashrc might lead to better organization, since it
70 allows you to use package atoms to specify which bashrc file(s) will be
71 sourced by a particular ebuild.
72
73 > In any case I tried package.bashrc but portageq envvar INSTALL_MASK does not print
74 > anything either. It occurred to me that portageq envvar is not the right tool see
75 > variable defined in bash scripts? Is there some other tools I can use?
76
77 There's no tool for this, but you can put an elog message in the bashrc
78 to provide an indication that it's working as expected.
79 --
80 Thanks,
81 Zac