Re: Seeking an idiot's guide to etcupdate/mergemaster

I am probably alone in this but I find the CVS style <<<<</>>>>>
markers in the update diffs intensely confusing. Given many merges are
large blocks, its almost impossible to keep context flitting about in
vi to find the old/new insertions. The odd thing is that post edit,
the view you get afterward is traditional diff/patch mode, so its
really bizarre: shown one way in edit mode, shown another in review
mode before commit.

There are far more urgent problems than fixing my 61 year old diff
format confusion, I don't think this justifies a bug report.

TL;DR the merge process for FreeBSD-update and like, can be intensely
confusing when you try to reconcile what it tells you about /etc/

-G

On Sun, Nov 6, 2022 at 12:07 PM Tomoaki AOKI <junchoon@dec.sakura.ne.jp> wrote:
>
> On Sat, 5 Nov 2022 20:12:04 -0700
> bob prohaska <fbsd@www.zefox.net> wrote:
>
> > On Mon, Oct 24, 2022 at 08:32:17PM -0700, Mark Millard wrote:
> > >
> > > Your /etc/rc.d/ldconfig script seems to have not been updated
> > > by use of etcupdate or mergemaster or other such. (How much
> > > else is also out of date? How much of what you have for /etc/
> > > and the like goes back to 2022-Jan-07 or before?)
> > >
> >
> > Alas, that is too true. The system was set up on July 2, 2020
> > and I've never managed to make sense of either mergemaster nor
> > etcupdate. Far as I could tell it didn't matter, the host ran
> > correctly, until now.
> >
> > It's been transplanted to a new hard drive, which allows the
> > installation of a ports tree. Ports don't install because of
> > the stale /etc/rc.d/ldconfig file.
> >
> > Since no changes have been made to /etc/ apart from /etc/rc.conf
> > is it possible to simply let mergemaster or etcupdate install
> > the latest defaults? I have looked at the manpage for etcupdate
> > and didn't recognize any straightforward way to simply accept
> > all updates. This particular system is expendable, so I'd be
> > glad to try things that might not work well, or at all.
> >
> > Apologies if I'm being dumb (probably guilty) or lazy (definitely
> > guilty). The barrage of questions generated by etcupdate  and
> > mergemaster is simply overwhelming. And, I suspect, largely
> > unnecessary.
> >
> > Thanks for reading!
> >
> > bob prohaska
>
> For a relatively casual way.
>
> If I'm facing the same situation, I will...
>
>  1. `mergemaster -UFiP` for now, then...
>  2. `etcupdate extract -B` for next upgrade.
>
> And on next upgrade, `etcupdate -p` before installing upgrade,
> and then `etcupdate -B` after install.
> You can add -n for dry-run before actual etcupdate.
>
>
> For some notes:
> mergemaster, the old and less maintained tool, uses current installation
> and updated tree. Old dedault state is not at all considered.
>
> So it could be used for already-updated states.
>
> etcupdate, the currently maintained tool, uses previous and updated
> defaults, and current installation (working environment).
> It compares differences between old and new default, check if the
> differences can be sanely applicable to currently working environment
> or not, and if it's sane, apply the diff automatically.
> If any conflict happenes, ask the admin (this case, you) for actions.
>
> So it requires previous default state, thus cannot use for this case,
> except you are sure what the actual previous revision was and can
> prepare the source tree (possibly obj tree, too?) and somehow create
> "current" tree ATM (will be turned over to "previous" tree on etcupdate
> run).
>
> See manpages for detail.
>
> --
> Tomoaki AOKI    <junchoon@dec.sakura.ne.jp>
>