Re: pkgsrc packaging of base?

[Csaba Henk <csaba.henk@xxxxxxx>]

On 2006-02-09, Simon 'corecode' Schubert <corecode@xxxxxxxxxxxx> wrote:
> config files (for ssh or inetd, for instance).  IMO we desperately need
> a wicked tool which do the right thing[tm].  something with three-way
> merges and stuff...

While such a tool would be cool, it might take some time while it gets
written.

[If you feel its off here, feel free to tell me to repost it as a thread
starter on users@.]

In the meantime, why not have something which is useable, damn simple
and isn't tied to that dreaded interactive event loop like mergemaster?

Some Linux distros just do this... Find out a sensible postfix (I use
"sysnew" now, although I don't claim it's a good choice), and for each
file foo in /etc, if it has changed, place the new version side-by-side
of foo as foo.sysnew. (To save us from self-shooting, the 
"make installworld" target would fail by default if /etc is not clean
from *.sysnew files at install time.)

It would be a good starting point. A simple find command could give an
overview of the files to be updated. And it wouldn't take more than a few
lines to provide a coarse drop-in-replacement for mergemaster:

  find /etc/ -name '.*sysnew' | while read f; do
    forig=`echo $f | sed 's/\.sysnew$//'`
    diff -u $forig $f | vim -c "set hidden" -c "vi $forig" -
  done

(I know vim is not in the base, indeed the point is that one can easily
apply her custom toolset to get things done.)

And then add a simple+stupid-but-slowly-improves utility script, say
etcmaster. It would have a bunch of subcommands. Eg. one for producing a
clean copy of either the old or the new /etc directory, so that you can
go back to good ol' mergemaster any time (even with a partly resolved /etc
dir). It could have a subcommand which scans through /etc and replaces
files with their *.sysnew incarnation if they differ in nothing else
just the RCS id (relaxing thusly my greatest objection against
mergemaster). It could have a subcommand to go over all the files which
are never touched by 99% percent of people (or reside in /etc/defaults, or
listed as "updatable" in a config file) and do update them. It
could have a subcommand to 3-merge three incarnations of /etc (useful if
you kept the old source tree from which you upgrade, which is possibly
the case for most people). And so on. New subcommands would be easy to
contribute.

Just stop mindless interactiveness and don't try to do everything but
the kitchen sink in one huge step and the bulk of the inconveniences
could go away quickly.

Regards,
Csaba