Usually precedence is: 1. Command-line flags, falling back to 2. Environment variables, falling back to 3. Config files But etc-update has: while [[ -n $1 ]] ; do case $1 in -d|--debug) SET_X=true;; … esac shift done … get_config "($(printf '%s|' "${cfg_vars[@]}")NOVARFOROLDMEN)" which means things like the rm_opts set by parse_automode_flag is getting clobbered by the config-file version. Reproducible: Always Steps to Reproduce: 1. Have some /etc config script to update 2. echo 'YES' | etc-update --automode -9 Actual Results: Scanning Configuration files... Deleting /etc/layman/._cfg0000_layman.cfg rm: remove regular file '/etc/layman/._cfg0000_layman.cfg'? Exiting: Nothing left to do; exiting. :) NOTE: 1 updates remaining Expected Results: Actually remove the update. Shifting the argument-parsing while-loop after the get_config command fixed the problem.
Although obviously you'd want to keep stuff like `${SET_X} && set -x` after the argument parsing. I wouldn't be surprised if things like NONINTERACTIVE_MV could be removed (sticking to mv_opts) too. I haven't had time to internalize the script well enough to write a patch addressing that sort of thing, but I'll get to that eventually if this languishes for too long ;).
almost the correct assignee ;)
(In reply to Brian Dolbec from comment #2) > almost the correct assignee ;) Ah, thanks :p. I usually just peak at a few existing bugs to figure out what these should be for a package (maybe we should list them in metadata.xml?). In this case "Tools" and "Core Configuration" seemed popular [1] ;). [1]: https://bugs.gentoo.org/buglist.cgi?quicksearch=etc-update