John Nemeth writes:
> On Jan 31,  6:04pm, Luke Mewburn wrote:
> } > Perhaps this could be based on how folks typically track kernel config
> } > file changes - keep a copy of the default file, and diff that against
> } > a copy of the new default file to see what needs to be changed in the
> } > actual in-use file. I'm sure this could be automated easily enough to
> } > take much of the grunt work out of it.
> 
>      This was one of the suggestions that was made in a previous
> discussion about this topic.  This idea makes a lot of sense and would
> be a perfect solution to the problem at hand.  Another suggestion was
> to use RCS, but I think that would be overkill for most sites.
> However, as long as it didn't get in my way, like the current change
> does, I wouldn't object.

I currently *use* RCS for managing my /etc/ config files, and
in the older scheme, manually upgrading /etc/rc.conf from
/usr/src/etc/rc.conf was not trivial.

Using CVS, vendor branches, and CVS merging might help a bit, but that
can be overkill for many users, although I have considered it, only
prevented by the lack of time to do it at the moment.


> } Then, during a (manual) upgrade of /etc (to take advantage of new
> } programs or startup, or changed options - such as the replacement
> } of portmap with rpcbind), you might want to find out what changed,
> } so you'd run diff(1) between /usr/src/etc/rc.conf and /etc/rc.conf.
> } Of course, because you'd changed /etc/rc.conf for your site
> } preferences, it was a bit difficult to peruse the diff(1) output for
> } stuff that you changed versus stuff that was changed in the source
> } tree. I speak from long experience fighting this battle :/
> 
>      A tool to do a three way merge between the old config file, the
> modified one, and the new config file could easily be developed to
> assist with this.

I've noticed an interesting thing in these discussions about
modifying the way that NetBSD is configured and managed:

	People are quick to jump up and suggest that a tool
	``could easily be developed'', but few actually do
	the work and write the said tool which results in an
	easy to use, maintainable, and flexible tool.

	If it was that easy, why hasn't it been done already?
	This upgrade problem has annoyed people ever since
	we shipped with rc.conf, yet no tool has been provided
	so far...

I've also been involved in supporting this problem in the field
in other OSes that use a similar rc.conf concept (both natively
and hacked in by us) for many years.


> } 	* Certain people started using this as a way to add overrides
> } 	  to /etc/rc.conf and kept /etc/rc.conf `virginal'. I picked
> } 	  this habit up from Matt Green, because it made sense.
> 
>      No, it doesn't.  It's the same thing that you created now (look in
> one file for the available options and their defaults, then make the
> change in another file).

Except that if you don't like what we have now, you can do this:
	cp /etc/default/rc.conf /etc/rc.conf
and you're back to where we used to be, sans the rc.local.conf stuff
which was added post 1.4 (I think). Then you're free to write your
Wonder Merge Tool(tm).


> } Even with the in-line documentation, I generally find I refer to
> } rc.conf(5) anyway; it's usually more detailed than the short sentence
> } that describes a particular feature.
> 
>      I have never looked at that manpage.  For those that know what
> they are doing, the variables are pretty much self-explanatory, and the
> short comments are more then enough.  Anyways, I just took a look at
> that manpage on a 1.4.2 box (I don't have a 1.5 box handy at the
> moment), and found it to be incomplete.

I spent a reasonable amount of time ensuring that the documentation
for rc.conf(5) et al was up to date because it SHOULD be a useful
reference. 

Relying upon a 3-4 word short comment in /etc/default/rc.conf to
adequately describe a feature is not the best thing.

I don't appreciate you criticising us for suggesting that you use 
a manual page in a given release relevant to a change added in that
release. That's like complaining that new ftp features that would be
first visible in 1.5 weren't documented in 1.4.2...



I don't think there is One True Way for supporting upgrades of
configuration files, especially given that NetBSD (unlike commercial
OS releases) has to cope with people upgrading from a release or
-current.

I've also seen how those commercial systems try and assist you in the
upgrade process, and you still end up with a bunch of files where you
manually have to check them. The `advantage' those systems have is
that they generally don't change much in configuration, and if they
do, there's a whole team that can be setup by the vendor to ensure
that scripts and migration tools exist to go from (for example)
Solaris 2.5 -> 2.6.

We've had to compromise because there isn't One True Way. I think we
now provide something that is fairly simple (compared to other
solutions) in terms of maintainability and understandability, and 
allows the people who are working on future NetBSD releases to improve
the upgrade mechanism for users on 1.5.


Luke.