See below; emerge says there is only one file to update, when etc-update says there are 125 ... this log comes from my console after Gimp build failed. Ok, there is only ONE file in "/etc" to update ... but, this is irrevelant; both commands should count the same way: either emerge also counts /usr, or etc-update should NOT go there. make[1]: Leaving directory `/var/tmp/portage/app-doc/gimp-help-0.13/work/gimp-help-2-0.13' make: *** [install-am] Error 2 * * ERROR: app-doc/gimp-help-0.13 failed. * Call stack: * ebuild.sh, line 1654: Called dyn_install * ebuild.sh, line 1089: Called qa_call 'src_install' * ebuild.sh, line 44: Called src_install * gimp-help-0.13.ebuild, line 51: Called die * * make install failed * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/var/log/portage/app-doc:gimp-help-0.13:20070927-234121.log'. * * GNU info directory index is up-to-date. * IMPORTANT: 1 config files in '/etc' need updating. * See the CONFIGURATION FILES section of the emerge * man page to learn how to update config files. root@moon_gen_2:/tmp# etc-update Scanning Configuration files... df The following is the list of files which need updating, each configuration file is followed by a list of possible replacement files. 1) /etc/bash_completion.d/ooffice.sh (1) 2) /usr/share/X11/xkb/symbols/ad (1) 3) /usr/share/X11/xkb/symbols/af (1) [...] 123) /usr/share/X11/xkb/rules/xfree98 (1) 124) /usr/share/X11/xkb/rules/xkb.dtd (1) 125) /usr/share/X11/xkb/symbols/za (1) Please select a file to edit by entering the corresponding number. (don't use -3, -5, -7 or -9 if you're unsure what to do) (-1 to exit) (-3 to auto merge all remaining files) (-5 to auto-merge AND not use 'mv -i') (-7 to discard all updates) (-9 to discard all updates AND not use 'rm -i'):
Created attachment 132054 [details] /tmp/emerge--info
(In reply to comment #0) > Ok, there is only ONE file in "/etc" to update ... but, this is irrevelant; > both commands should count the same way: either emerge also counts /usr, or > etc-update should NOT go there. It's only supposed to scan the directories listed in CONFIG_PROTECT since scanning all directories us often prohibitively time consuming. Here is your setting: CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config" Since /usr/share/X11 isn't listed in CONFIG_PROTECT I suspect that this has something to do with symlinks. I won't have the solution until do some more investigation.
It seems like you might have a symlink from somewhere in /usr to somewhere in /etc, or vice versa. I don't understand exactly why etc-update is listing the files in /usr/share/X11 but not emerge, since they are both supposed to use the same find options. Perhaps you have a non-standard version of etc-update? You can use `which etc-update` to find out which one you're using. Normally it is /usr/sbin/etc-update which is a symlink to /usr/lib/portage/bin/etc-update.
This bug seems to be an interaction between the modification of CONFIG_PROTECT via /etc/env.d/10xkeyboard-config (installed by at least some versions of xkeyboard-config) and the way that emerge considers the calling environment to override configuration file settings. If a variable from /etc/env.d is modified, the old value will continue to exist in the environment until you run 'source /etc/profile'. I'm afraid that there may not be a consistent way to fix this while keeping the long standing behavior of allowing the calling environment to override configuration file settings.
Another interaction the needs to be considered for this bug is addition/removal of CONFIG_PROTECT paths during the course of package installation/upgrade/removal. Maybe it would be best not to have any packages modifying CONFIG_PROTECT via /etc/env.d due to these types of interactions. They can either do it via the profile or we may want to devise some new mechanism for this.
(In reply to comment #5) > Another interaction the needs to be considered for this bug is addition/removal > of CONFIG_PROTECT paths during the course of package > installation/upgrade/removal. Maybe it would be best not to have any packages > modifying CONFIG_PROTECT via /etc/env.d due to these types of interactions. > They can either do it via the profile or we may want to devise some new > mechanism for this. I wouldn't be in favor of a profile based solution. Those settings aren't profile-dependant in any way and would also cause complications with overlays (due to users having to use overlay profiles). So either it's solved on a per-package base (preferrable) or at the repository level.
Sorry for late; see bug 194716 dhp@moon_gen_2:~$ which etc-update /usr/sbin/etc-update dhp@moon_gen_2:~$ equery b /usr/sbin/etc-update [ Searching for file(s) /usr/sbin/etc-update in *... ] sys-apps/portage-2.1.3.11 (/usr/sbin/etc-update -> ../lib/portage/bin/etc-update) dhp@moon_gen_2:~$ ls -l /usr/sbin/etc-update lrwxrwxrwx 1 root root 29 2007-10-01 12:44 /usr/sbin/etc-update -> ../lib/portag e/bin/etc-update dhp@moon_gen_2:~$ ls -l /usr/sbin/etc-update lrwxrwxrwx 1 root root 29 2007-10-01 12:44 /usr/sbin/etc-update -> ../lib/portage/bin/etc-update dhp@moon_gen_2:~$ equery b /usr/sbin/../lib/portage/bin/etc-update [ Searching for file(s) /usr/sbin/../lib/portage/bin/etc-update in *... ] dhp@moon_gen_2:~$ Running 'source /etc/profile' should not be a problem; I shutdown compleetely (not sleep). So, I re-login every morning. Except if /etc/env.d have been modified by an emerge done in the day. Maybe, using date of creation of this bug, I could give you the logs of what I emerged that day ? Do you want to give me a command that would list all symlinks in etc and usr ? I am not a "find" master. Maybe we could first try to reproduce this bug using some choosen "touch", creating a fake file, and check if this was due to in-day emerge/update. Calling etc-update is easy for me; what I dont know how to do, is to call the routine emerge calls before exiting ... to compare the results. I really think we should first dig my emerge logs on that day, and try to reproduce first. Find is also a cheap test.
There's no need to reproduce anything since we've already determined the cause (comment #4).
(In reply to comment #8) > There's no need to reproduce anything since we've already determined the cause > (comment #4). > I prefer to reproduce first, so that when I apply fix, I can check the fix works (then remove the fix, check it breaks, and put it back). Unles you are 100% of your idea in #4. Good luck :)
Yes, the problem is 100% understood. You'd only be wasting time.
I guess I encountered a variation of this problem here as well. I found several ._cfg????_* files on my system while dispatch-conf listed none. They belonged to xkeyboard-config and several texlive packages. As a result of this, I had files on my system that never got merged. I would wish for emerge to notice any change in config protection, and to take the config protection settings from after the update into account when merging the package. So when things get protected for the first time, they are protected from the moment the protecting version was merged. If dirs loose their protection, the merge dropping that protection would be correctly merged. As for how to achive this in terms of user interface and environment: There should be files specifically for config protection, e.g. /etc/portage/config.protect/* or some such. Settings on the environment should be considered changes relative to the default specified in those files. I.e. normal entries get added, while entries prefixed with - get subtracted, just as it works for USE when combining environment with /etc/make.conf. "-*" should remove all protections or masks. With this, the new mechanism would be in place, but the old ways would still work. In a next step, packages should be switched over, i.e. told to use those new files instead of env.d. You could probably add some QA hook for this, and grep the portage tree for CONFIG_PROTECT to list affected packages. Once migration is complete, CONFIG_PROTECT* in the calling environment can be empty by default. portage knows which part of the configuration is requested by the admin and which configured by ebuilds. For the latter, it can track changes and act accordingly, as outlined above. This step three could be started even while packages are moving over to those new files.
*** Bug 349683 has been marked as a duplicate of this bug. ***
