from etc-update: ... 4) Show differences again Please select from the menu above (-1 to ignore this update): 1 Replacing /etc/X11/app-defaults/XLock with /etc/X11/app-defaults/._cfg0000_XLock ... But because there was no /etc/X11/app-defaults/XLock file before it cannot be replaced. Reproducible: Always Steps to Reproduce: 1. 2. 3.
If there was no /etc/X11/app-defaults/XLock before, there would be no ._cfg0000_XLock. So, please explain better.
"Replacing _foo_ with _bar_" should be better written as "Renaming _foo_ to _bar_" because there is nothing to "replace" in that case
(In reply to comment #2) > "Replacing _foo_ with _bar_" should be better written as "Renaming _foo_ to > _bar_" because there is nothing to "replace" in that case What do you mean "there is nothing to replace"? Where did the updated configuration file come from then? I really don't understand you request.
Thinking a bit longer about this of course your right - at the point where etc- update is acting, there should exists a file which has to be replaced by a newer version. I know it is strange but I am sure that there was no /etc/X11/app- defaults/XLock before. Closing this bug until I discover it again.
/usr/X11R6/lib/X11/app-defaults is a symlink to /etc/X11/app-defaults. Older versions of xlockmore install /usr/X11R6/lib/X11/app-defaults/XLock. Newer versions of xlockmore install /etc/X11/app-defaults/XLock. So when the new version is installed, it installs /etc/X11/app-defaults/._cfg0000_XLock (since /etc/X11/app-defaults/XLock still exists and it's protected), but when the old version is cleaned out immediately afterwards, /usr/X11R6/lib/X11/app-defaults/XLock is removed (since it's unchanged and unprotected), leaving /etc/X11/app-defaults/._cfg0000_XLock without the original XLock file. I don't know if changing the wording for this very rare case is worth the effort, though.
(In reply to comment #5) > I don't know if changing the wording for this very rare case is worth the > effort, though. The author of etc-upate should be aware of the fact that indeed there could be a .cfg_* file without the original. This -rare- case could result in an unexpected error if a command to backup the original file fails.
The original file is never backed up anyway, so that is not a problem. But etc-update does behave strangely when the user chooses to merge, and deletes without special warning if the user wishes to keep the original file.
Not really sure how to classify this one, also the original report is missing the actual problem ("But because there was no /etc/X11/app-defaults/XLock file before it cannot be replaced." is hardly a useful problem description here). Also the symlink seems to be gone by now.
Sorry for the bad original report. What I meant is that etc-update should use the term "Replacing" only if it would replace an existing config file wit a new one. This bug is obsolete if /etc/._cfg0000_foo* is created only in cases where /etc/foo is not automatically created or overwritten by emerge. That seems now to be true so I close this bug now.
