RFT: bin/106642: [patch] Allow excluding certain files from mergemaster (8)

[Doug Barton]

Gaspar Chilingarov wrote:

> Well another question -- is it possible teach somehow mergemaster, that
> it should never touch passwd, groups, /etc/ttys or bunch of another files?

Sure, you just do the opposite of what I did in the last script. If
the file doesn't exist in the temproot when it's time to start
comparing, mergemaster will never do anything with it. So here is some
more out of the script that I actually use:

#!/bin/sh
# NOTE: No PATH needed, because mm's PATH is already draconian enough
case "${PRE_WORLD}" in
'')     rm -f /etc/defaults/pccard.conf
        rm -f ${TEMPROOT}/etc/motd
        rm -f ${TEMPROOT}/etc/printcap
	rm -f ${TEMPROOT}/etc/namedb/named.*
        ;;
esac

> About pre-script which you suggested, there is another problem -- I MAY
> have new scripts in /etc/rc.d, but NEVER change the system's scripts.

Simple answer, don't do that. Put your scripts in /usr/local/etc/rc.d
instead, and as of 6.1 and newer they will be included in the base
rcorder. Therefore there will be no difference in when they are run.
There is a default assumption that stuff in /etc/rc.d is the systems,
and the systems only. Now that local scripts (including ports) are in
the base rcorder, there is no reason not to do it that way.

> In other hand running rm /etc/rc.d/* before mergermaster's start can
> render system unusable, if mergemaster will fail for some reason.

That's a good reason to do the update in single user mode, and always
keep good backups. :) Please understand that I am not advocating that
anyone actually DO what I suggested, I'm just pointing out that there
are alternatives that already exist that can accomplish what people
want to do here.

Having given it a little more thought, it would probably be safer to
do something like:
case "${PRE_WORLD}" in
'')     mv ${TEMPROOT}/etc/rc.d/* /etc/rc.d/
	;;
esac

But my basic point is the same. I added MM_PRE_COMPARE_SCRIPT and
MM_EXIT_SCRIPT to give users MORE flexibility than adding more (and
more complex) CLI options would do. Please take advantage of it. :)

Doug

-- 

    This .signature sanitized for your protection