On 08/11/2015 11:11 AM, Joakim Tjernlund wrote: > 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?
You can, but package.bashrc might lead to better organization, since it allows you to use package atoms to specify which bashrc file(s) will be sourced by a particular ebuild. > 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? There's no tool for this, but you can put an elog message in the bashrc to provide an indication that it's working as expected. -- Thanks, Zac
