generalized mergemaster(8)

[Friedemann Becker]

the promised fix for the -p problem:

put this at the top of mergemaster.pre
PRE_WORLD is set in case of -p, so just do nothing and return to
mergemaster


case "${PRE_WORLD}" in
  '') ;;
  *) return ;;
esac


cheers,
Friedemann


On Sun, 6 Apr 2003, Friedemann Becker wrote:

> I wrote this little script, it runs as MM_PRE_COMPARE_SCRIPT.
>
> there are 2 functions, mupdate and mignore.
>
> mupdate installs the specified file(s) without asking,
> mignore deletes the specified file(s).
>
> note that in this example etc/mtree is an directory, it's recursively
> worked through, so all files beyond etc/mtree will be installed.
>
> the file location is specified relative to root, so most entries will
> start with etc/
>
> also, mupdate only deletes files, if there are differences between the
> temporary version and the installed one.
>
> there is one bug though!
> mergemaster -p (pre-build mode) installs the complete temporary root tree,
> but will only want to install a few files of it.
> mignore files get deleted, but that doesn't hurt anyone, we don't want it
> to get updated anyway.
> but mupdate can delete installed files that won't be updated be mergemaste
> r -p, so they are missing until mergemaster is run without the -p flag.
> So if do your make world in the order described in the handbook, you would
> boot the new kernel after mergemaster -p, but before real mergemaster.
> This is where it could happen that critical files are missing and your
> system is left in an unusable state.
>
> I'm working on a solution to this, but if someone likes to help me, here
> is, what i've done so far ;))
>
> Friedemann
>
>
>
>    ---  /etc/mergemaster.rc  ---
> MM_PRE_COMPARE_SCRIPT=/home/lucius/cvsup/mergemaster.pre
>
>    ---  /home/lucius/cvsup/mergemaster.pre  ---
>
>
> #!/bin/sh
>
> mupdate() {
>         for i in $(find $1 -not -type d)
>                 do mupdate1 $i
>                 echo $i >> ~/log
>         done
> }
>
> mupdate1() {
>         [ -e $1 ] && diff $1 /$1 || rm -rf /$1
> }
>
> mignore() {
>         for i in $(find $1 -not -type d)
>                 do mignore1 $i
>                 echo $i >> ~/log
>         done
> }
>
> mignore1() {
>         [ -e $1 ] && rm -f $1
> }
>
> mupdate etc/mtree
> mupdate etc/pam.d
> mignore etc/ppp/ppp.conf
> mupdate etc/rc.d
> mupdate etc/devd.conf
> mignore etc/hosts
> mignore etc/motd
> ...
>
>
>
>
> On Sun, 6 Apr 2003, David O'Brien wrote:
>
> > On Sun, Mar 23, 2003 at 12:06:06PM +0100, Michael Ranner wrote:
> > > Am Freitag, 21. M?rz 2003 20:27 schrieb Garance A Drosihn:
> > > > >
> > > > >  /var/tmp/temproot/etc/rc.d/ and /etc/rc.d/ have 17 differing files.
> > > > >  (I)nstall, (D)elete, or (R)ecursively examine? [R]
> > > > >
> > > > >Then I could hit 'I' and update all of /etc/rc.d at once.
> > > >
> > > > At times I've asked Doug about some kind of pattern-support in
> > > > ~/.mergemasterrc, where the user could specify filename-patterns
> > > > of files where they want the default action to be "install"
> > > > instead of "leave for later".  There are pros and cons with that
> > > > idea, but that's what I was thinking of for the directories you
> > > > describe.
> > > >
> > > > Doug has suggested that people could maybe do things with the
> > > > MM_PRE_COMPARE_SCRIPT, for special processing like this.
> > >
> > > I have a small patch for pattern-support in ~/.mergemasterrc and
> > > already sent my ideas to Doug, but he said "It could/should
> > > be done with MM_PRE_COMPARE_SCRIPT" to me.
> >
> > Could you post them??
> >
> > Dougb says that all the time, but has never created an example that will
> > do what 90% of us want.  Every time the desire for this comes up, dougb
> > says it is outside of the envisioned purpose of mergemaster.  Seems to me
> > that if the tool isn't meeting the desires of 90% of your user base, maybe
> > it could grow the functionality desired....
>
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
>