W dniu 3.12.2021 o 14:54, Jeffrey Bouquet pisze:
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: [...]
Thank you Yetoo for describing your experience, bringing the topic again and provoking this discussion.
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 LachmanAgree. 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
So do I.
Some people are pushing toward etcupdate(8) for the automation and 3-way merge support, but updating old STABLE with this tool could be really stressful and time-consuming challenge. How would one for example find old sources to perform "etcupdate extract" ?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.
From my experience etcupdate(8) is only useful for updating RELEASEs or frequently updated CURRENT. The power of sdiff(1) way merge giving full control over the update process is the real strength of cursed mergemaster(8). Maybe it's a barrier for people not familiar with vi(1) and requires more time per update, but so far never failed me. The missing $FreeBSD ...$ IDs can be regenerated in local git repo with smudge filters. Generating locally these IDs for the specific set of files which mergemaster(8) operates on doesn't slow down the repository and shouldn't be considered as argument for deprecation and removal of mergemaster(8).
I tried to use etcupdate(8) for STABLE a few times, but the ricochet shot my foot once or twice, so stepped back. I still maintain what I have written earlier, that a well-worn hammer could be in some cases better than a nailgun.
Biased, 20+ years FreeBSD and mergemaster(8) user, -- Marek Zarychta
OpenPGP_signature
Description: OpenPGP digital signature
