On 8/13/15 11:23 PM, John Baldwin wrote:
On Thursday, August 13, 2015 04:13:43 PM Slawa Olhovchenkov wrote:
On Tue, Aug 04, 2015 at 10:00:06PM -0700, John Baldwin wrote:

On Sunday, July 26, 2015 03:26:22 AM Baptiste Daroussin wrote:
Hi all,

I was botherd to not have the merge(1) utility available in base (for etcupdate)
when building base WITHOUT_RCS.

So I have rewritten a merge(1) utility which should be compatible.

I used the 3-way merge code from the fossil VCS instead of making it call diff3.
All I have done from the fossil code is adapting it to use sbuf(9).

The bonus for end users is the merge from fossil can resolve situation where the
diff3 in base cannot. (which explains a "failure" with the GNU RCS test suite)

meaning etcupdate will be more happy merge configuration files.
Thanks!  This will save me from having to hack etcupdate to use diff3 instead
of merge.
Hi, can I use etcupdate to update /etc w/o source tree?
I.e. I take from new distro /var/db/etcupdate and try to update /etc?
etcupdate does a 3-way merge of an "old" stock /etc and a "new" stock /etc
into /etc.  The "old" stock /etc is always stored in /var/db/etcupdate.
The "new" stock /etc has to come from somewhere.  One option is to generate
it from /usr/src (e.g. after a buildworld).  However, you can also pregenerate
tarballs from a /usr/src tree on one machine and then use those tarballs
instead of generating an /etc tree from /usr/src on another machine.  I've
used this for upgrades of a cluster of machines where a single machine would
build release "images" that were basically a buildworld + an 'etcupdate build'
from the corresponding src tree.  I then used 'etcupdate -t /path/to/tarball'
to update /etc after installing the new world.

The idea is that for something like freebsd-update one could ship the latest
etcupdate build tarball on each update to do a full 3-way merge of /etc.

what is the rational for using etcupdate instead of mergemaster when upgrading?
freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to