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
Steps to Reproduce:
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
I know it is strange but I am sure that there was no /etc/X11/app-
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
I don't know if changing the wording for this very rare case is worth the
(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.