freebsd stable - Mar 2015 - There has to be a better way of merging /etc during a major freebsd-update

This flag to mergemaster saved a lot of work when I did
upgrades the old way, with cvsup and the make steps and
then mergemaster:
"
# Install the new file if it differs only by VCS Id ($FreeBSD)
FREEBSD_ID=yes
"
Is there some equivalent to this flag in freebsd-update/merge?

I just did my first major upgrade (8.4-RELEASE-p24 ->
9.3-RELEASE-p10) with freebsd-update. It took more than
an hour of manual keyboard activity, most of which could
probably be done automatically. (And here I thought that
computers were supposed to free us from tedious routine
work...)

First robotically pressing dd..j.ZZ in a lot of files.
Occasionally combined with /<<< to find more places that
needed changing in files that didn't fit in the screen.
Eg sendmail.cf.

Of all these files that needed manual editing I had made
my own changes in only one file (/etc/hosts), the rest of
them just had this kind of change:

The following file could not be merged automatically: /etc/rc.d/nisdomain
Press Enter to edit this file in vi and resolve the conflicts
manually...

<<<<<<< current version
# $FreeBSD: src/etc/rc.d/nisdomain,v 1.5.2.2 2013/03/28 13:02:44 svnexp Exp $
======# $FreeBSD: releng/9.3/etc/rc.d/nisdomain 193197 2009-06-01 04:55:13Z
dougb $
>>>>>>> 9.3-RELEASE
And then, after all these edits, I had to wade through entering
y to "Does this look reasonable (y/n)?" for all these files!
This is of course a necessary step to avoid being bitten by
any <<< === >>> lines left behind by mistake (easy to do when
you lose your concentration after more than a hundred files),
but most of this step could be entirely avoided by automatically
accepting the ID changes.
(I amused myself by counting all files during this stage.
I had to answer y to about 320 files, most of which only
had changes in the ID.)

This was my first upgrade from 8.4 to 9.3. I have 30 more to go
before the 8.4 EoL this summer. I see 30 completely unnecessarily
wasted hours in my future...
And think of the combined lost man hours worldwide in these upgrades!
Merge seems to be a really stupid choice for major upgrades.
(Unless of course there is some flag to freebsd-update which makes
this kind of change automatically accepted. But I see no such flag
in man freebsd-update in 8.4, 9.3 or 10.1.)

And yes, I could maybe copy most of /etc from the first
upgraded server to the rest of them before upgrading, but
that seems error-prone and not really a good solution for
every FreeBSD user.

-- 
Peter Olsson

Peter Olsson wrote on 03/10/2015 13:05:
[...]
> (I amused myself by counting all files during this stage.
> I had to answer y to about 320 files, most of which only
> had changes in the ID.)
>
> This was my first upgrade from 8.4 to 9.3. I have 30 more to go
> before the 8.4 EoL this summer. I see 30 completely unnecessarily
> wasted hours in my future...
> And think of the combined lost man hours worldwide in these upgrades!
> Merge seems to be a really stupid choice for major upgrades.
[...]

This and some other problems with freebsd-update (hanging on the reboot 
after update) turns me back to using source compiled upgrades.
I am compiling 10.1 right now to do the upgrades from 8.4 to 10.1 on 15 
machines.
Once compiled, I will NFS mount /usr/src and /usr/obj to all machines 
and will run installkernel, installworld and mergemaster with customized 
.mergemasterrc.
It is more reliable and predictable upgrade, than freebsd-update.
(I used freebsd-update for many years, but enough is enough)

Miroslav Lachman

PS: on PC-BSD there is etcupdate for merging changed files in /etc

Hi!
> This flag to mergemaster saved a lot of work when I did
> upgrades the old way, with cvsup and the make steps and
> then mergemaster:
> "
> # Install the new file if it differs only by VCS Id ($FreeBSD)
> FREEBSD_ID=yes
> "
> Is there some equivalent to this flag in freebsd-update/merge?
> 
> I just did my first major upgrade (8.4-RELEASE-p24 ->
> 9.3-RELEASE-p10) with freebsd-update. It took more than
> an hour of manual keyboard activity, most of which could
> probably be done automatically. (And here I thought that
> computers were supposed to free us from tedious routine
> work...)
Well, I've been through this in the past as well. If it helps,
it gets much better with more recent versions of FreeBSD (9.3 -> 10.x).

So, yes, it's a drag, but it will not repeat in future updates.

-- 
pi at opsec.eu            +49 171 3101372                         5 years to go
!

On Tue, 10 Mar 2015 13:05:40 +0100 Peter Olsson <list-freebsd-stable at
jyborn.se>
wrote
> This flag to mergemaster saved a lot of work when I did
> upgrades the old way, with cvsup and the make steps and
> then mergemaster:
> "
> # Install the new file if it differs only by VCS Id ($FreeBSD)
> FREEBSD_ID=yes
> "
> Is there some equivalent to this flag in freebsd-update/merge?
Hello, Peter.
This has probably been answered by now. But just in case.
I believe what you're looking for is:
mergemaster -vF

This is my [chosen] default. I also find it helpful,
as a "safety net" to
cp _Rp /etc /eetc

prior to the mergemaster(8) step.

On a related note. I'm not very fond of mergemaster. As
a result, I recently took on maintaining
sysutils/etcmerge. sysutils/etcupdate, is also a
[mergemaster] related port.

Hope this helps.

--Chris
> 
> I just did my first major upgrade (8.4-RELEASE-p24 ->
> 9.3-RELEASE-p10) with freebsd-update. It took more than
> an hour of manual keyboard activity, most of which could
> probably be done automatically. (And here I thought that
> computers were supposed to free us from tedious routine
> work...)
> 
> First robotically pressing dd..j.ZZ in a lot of files.
> Occasionally combined with /<<< to find more places that
> needed changing in files that didn't fit in the screen.
> Eg sendmail.cf.
> 
> Of all these files that needed manual editing I had made
> my own changes in only one file (/etc/hosts), the rest of
> them just had this kind of change:
> 
> The following file could not be merged automatically: /etc/rc.d/nisdomain
> Press Enter to edit this file in vi and resolve the conflicts
> manually...
> 
> <<<<<<< current version
> # $FreeBSD: src/etc/rc.d/nisdomain,v 1.5.2.2 2013/03/28 13:02:44 svnexp Exp
$
> ======> # $FreeBSD: releng/9.3/etc/rc.d/nisdomain 193197 2009-06-01
04:55:13Z dougb $
> >>>>>>> 9.3-RELEASE
> 
> And then, after all these edits, I had to wade through entering
> y to "Does this look reasonable (y/n)?" for all these files!
> This is of course a necessary step to avoid being bitten by
> any <<< === >>> lines left behind by mistake (easy to do
when
> you lose your concentration after more than a hundred files),
> but most of this step could be entirely avoided by automatically
> accepting the ID changes.
> (I amused myself by counting all files during this stage.
> I had to answer y to about 320 files, most of which only
> had changes in the ID.)
> 
> This was my first upgrade from 8.4 to 9.3. I have 30 more to go
> before the 8.4 EoL this summer. I see 30 completely unnecessarily
> wasted hours in my future...
> And think of the combined lost man hours worldwide in these upgrades!
> Merge seems to be a really stupid choice for major upgrades.
> (Unless of course there is some flag to freebsd-update which makes
> this kind of change automatically accepted. But I see no such flag
> in man freebsd-update in 8.4, 9.3 or 10.1.)
> 
> And yes, I could maybe copy most of /etc from the first
> upgraded server to the rest of them before upgrading, but
> that seems error-prone and not really a good solution for
> every FreeBSD user.
> 
> -- 
> Peter Olsson
> _______________________________________________
> freebsd-stable at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscribe at
freebsd.org"

On Tue, Mar 10, 2015 at 7:05 AM, Peter Olsson <list-freebsd-stable at
jyborn.se
> wrote:
> This flag to mergemaster saved a lot of work when I did
> upgrades the old way, with cvsup and the make steps and
> then mergemaster:
>
https://svnweb.freebsd.org/base?view=revision&revision=221780

I'd venture to guess the script will work fine on older installs, but
testing should be done first.

-- 
Adam