On Tue, 2015-08-11 at 10:55 -0700, Zac Medico wrote: > On 08/11/2015 10:48 AM, Joakim Tjernlund wrote: > > On Thu, 2015-07-23 at 08:47 -0700, Zac Medico wrote: > > > 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 <ri...@gentoo.org> wrote: > > > > > > > > > > > > On Wed, Jul 22, 2015 at 8:05 AM, Joakim Tjernlund > > > > > > <joakim.tjernl...@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. > > > > Finally getting back to this after lots of distractions. > > I cannot get profile-formats = profile-bashrcs to work. > > I have in metadata/layout.conf: > > masters = gentoo > > profile-formats = portage-2 profile-bashrcs > > then in profiles/tmv3-target-overlay/profile.bashrc: > > INSTALL_MASK=xxxx > > Doing portageq envvar INSTALL_MASK just yields an empty line > > I guess I am missing something here? > > > > > > See the "man portage" for profile-bashrcs details. It uses > package.bashrc rather than profile.bashrc, so that explains why it's not > working for you.
hmm, I figured I could use profile.bashrc to set stuff for all pkgs? In any case I tried package.bashrc but portageq envvar INSTALL_MASK does not print anything either. It occurred to me that portageq envvar is not the right tool see variable defined in bash scripts? Is there some other tools I can use? Jocke
