Re: Make etcupdate bootstrap requirement due to previous mergemaster usage more clear in handbook

W dniu 3.12.2021 o 14:54, Jeffrey Bouquet pisze:
> 
> 
> On Fri, 3 Dec 2021 13:58:39 +0100, Miroslav Lachman <000.fbsd@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 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
So do I.

> 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.
> 
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" ?

 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