On 12/3/21 6:09 PM, Tomoaki AOKI wrote:
On Fri, 03 Dec 2021 05:54:37 -0800 (PST)
"Jeffrey Bouquet" <jbt...@iherebuywisely.com> wrote:
On Fri, 3 Dec 2021 13:58:39 +0100, Miroslav Lachman <000.f...@quip.cz> wrote:
On 03/12/2021 12:52, Yetoo Happy wrote:
[...]
Quick Start* and follow the instructions and get to step
7 and may think that even though etcupdate is different from mergemaster
from the last time they used the handbook they have faith that following
the instructions won't brick their system. This user will instead find that
faith in general is just a very complex facade for the pain and suffering
of not following *24.5.6.1 Merging Configuration Files* because the user
doesn't know that step exists or relevant to the current step and ends up
unknowingly having etcupdate append "<<<< yours ... >>>>> new" to the top
of the user's very important configuration files that they didn't expect
the program to actually modify that way when they resolved differences nor
could they predict easily because the diff format is so unintuitive and
different from mergemaster. Now unable to login or boot into single user
mode because redirections instead of the actual configuration is parsed the
user goes to the handbook to find out what might have happened and scrolls
down to find *24.5.6.1 Merging Configuration Files* is under *24.5.6.
[...]
That's why I think etcupdate is not so intuitive as tool like this
should be and etcupdate is extremely dangerous because it intentionally
breaks syntax of files vital to have system up and running.
If anything goes wrong with mergemaster automatic process then your have
configuration not updated which is almost always fine to boot the system
and fix it. But after etcupdate? Much worse...
I maintain about 30 machines for 2 decades and had problems with
etcupdate many times. I had ti use mergemaster as fall back many times.
Mainly because of etcupdate said "Reference tree to diff against
unavailable" or "No previous tree to compare against, a sane comparison
is not possible.". And sometimes because etcupdate cannot automatically
update many files in /etc/rc.d and manual merging of a lot of files with
"<<<< ==== >>>>" is realy painful while with mergemaster only simple
keyboard shortcuts will solve it.
All of this must be very stressful for beginners.
So beside the update of documentation I really would like to see some
changes to etcupdate workflow where files are modified in temporary
location and moved to destination only if they do not contain any syntax
breaking changes like <<<<, ====, >>>>.
Kind regards
Miroslav Lachman
Agree. I fell back to mergemaster this Nov on 13-stable when the /var files
pertaining to etcupdate were all missing current /etc data, and no study of
man etcupdate was clear enough to rectify such a scenario, and suspect my
initial use of etcupdate will or may require a planned reinstall, not having
had to do so since Jan 2004 iirc, [ vs failed hard disk migrations ] and
I am just hoping mergemaster stays in /usr/src and updated
for system changes, even if moved to 'tools' or
something, since its use seems intuitive and much less of a black box.
Also, /usr/src/UPDATING still at the bottom emphasizes mergemaster still.
Not sure it's fixed or not (tooo dangerous to try...), -n (dry-run)
option of etcupdate is now quite harmful. Maybe by any commit done in
this april on main (MFC'ed to stable/13 in june).
*I got busy manually checking and applying changes to /etc, and
forgot to file PR.
Doing `etcupdate -n` itself runs OK, but following `etcupdate -B` does
NOT do anything, hence nothing is actually updated.
The only workaround I have is NOT to try dry-run.
Humm.
It would be because the same trees are used for dry-run and actual run.
(Not looked into the code. Just a thought.)
So the new changes always build a temporary tree (vs trying to build
/var/db/etupdate/current in place). For -n it should be that it just
doesn't change /var/db/etcupdate/current at the end, but if it did the
move anyway that would explain the bug you are seeing. That does indeed
look broken. Please file a PR as a reminder for me to fix it.
--
John Baldwin
