Re: make upgrade overwrites /etc/mail/mailer.conf

["Simon 'corecode' Schubert" <corecode@xxxxxxxxxxxx>]

On Thursday, 10. February 2005 07:06, Chris Pressey wrote:
> >     I think the goal ought to be a layout that does not require
> >     merging to update a system.  Mergemaster may be fine for a UNIX
> >     expert, but it's hell for a general user.

i have to agree there, it should be as easy and streamlined as it can get. 
BUT: somebody changing stuff in /etc/services can't be considered as a 
general user. If I change my rc.d scripts, I am likely an UNIX expert 
(well, at least i know how to adjust my rc.d scripts).

so maybe we should try to support two areas:

1. common changes by general users. that's not much, rc.conf, 
passwd/groups, resolv.conf, hosts, ssh/*_config

these should be updated as easy as possible. but well, defaults work well 
with rc.conf, but then it gets harder.

I still think a three way merge would be the best, but for the general 
user not using a unified diff, but plain english text. example (made up):

You have changed the file `/etc/ssh/sshd_config' before. An update to this
file is available. I can help you updating your copy.

The following section is an excerpt of the original file:
...
# session checks to run without PAM authentication, then enable this but
# set
# ChallengeResponseAuthentication=no
#UsePAM no

#AllowTcpForwarding yes
#GatewayPorts no
...

You changed it to read:
...
# session checks to run without PAM authentication, then enable this but
# set
# ChallengeResponseAuthentication=no
UsePAM yes

#AllowTcpForwarding yes
#GatewayPorts no
...

Unfortunately, I can't transfer your change to the new version. Please 
help me with that; the new pristine version reads:
...
# session checks to run without PAM authentication, then enable this but
# set
# ChallengeResponseAuthentication=no
#UsePAMAuthentication no

#AllowTcpForwarding yes
#GatewayPorts no
...

Please change the text to suit your needs.


Ah well, a little bit long. But most changes can actually be applied 
without collisions. Which means the user just gets presented (if he opted 
in/not out) his changed version and the new merged version. most time 
they will just say "yes, okay, that looks good. where was the change 
anyways"

> What do people think about using CVS for this?

I'd rather use RCS, the remote and can-checkout multiple times features 
are not needed here.

> - Standard tool with general applicability, in the base system.
> - Designed for handling merges and any conflicts that arise.
> - The admin can specify which files not to touch, using .cvsignore.
> - The admin can make unobtrusive comments on their changes, in the log.
> - The admin can roll back their configuration to any previous point.

all that is possible with RCS, too

> - The admin can keep the master configuration repo on another machine.

well, you need CVS for that. after all, both could be used interchangably.

> - Heavyweight solution; it's overkill.

only if you perceive it as CVS as a general user. if you don't notice 
anything about it, it's okay.

> - It's yet another component to administrate; more hassle.

if done properly, only for (us) programmers.

> - Its method of handling conflicts is less than optimal.

true. does cvs even do a three way merge? needed to be done better then.

> - The admin can't use its features from single-user mode.

true, but these are additional features, so there is no loss in comparison 
to now. or an /sbin/etctool gets linked statically.

cheers
  simon

-- 
/"\
\ /
 \     ASCII Ribbon Campaign
/ \  Against HTML Mail and News

Attachment: pgp00004.pgp
Description: PGP signature