On Feb 5,  1:40pm, Luke Mewburn wrote:
} 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.

     However, rc.conf is far better then what was there before where
one had to integrate changes to a bunch of shell scripts.  Our rc.conf
is also far better then the one in FreeBSD.  I recently installed the
latest snapshot of FreeBSD-CURRENT, and their rc.conf was full of
obscure variables with no comments, apart from one that said it was
created by sysinstall.

} > } 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...

     A number of people have volunteered to write tools for handling
rc.conf and some have even produced prototypes.  In any event, the
person that has the idea may not have the time/skills/etc. necessary to
write the tools, and there may be people that can do it, but don't have
the ideas.  There is certainly no requirement for the person that has
an idea to keep quiet until they implement it.  If this was the case,
then many good ideas would never see the light of day.

} 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.

     Your solution really doesn't help me much (I have many machines
spread all over the city to maintain).  You make more work for me,
since I have to look in one file and then make changes in another
file.  At upgrade time, I need to compare the old and new /etc/default
files to see what has changed in order to make any necessary changes to
the /etc files, which is an additional step that wasn't there bofore.
Or, I could just start my /etc files from scratch.

} > } 	* 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

     I just may do that.  However, I recall a discussion about
rc_configured that indicated that it might not be that simple.  I'll
have to look into it.  I don't really care about the rc.local.conf
stuff.

} > } 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. 

     It should be a useful reference for inexperienced people, but it
shouldn't be needed by people that are experienced.

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

     Given my experience, I find them to be more then adequate.

} 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 think there is a misunderstanding here.  I meant that the
manpage was incomplete with respect to its release.  For example the
1.4.2 rc.conf manpage doesn't say anything about the wscons variable,
which was added sometime during 1.4.  There may or may not have been
other problems; I didn't examine it all that thoroughly.

     Saying that 1.5 features aren't documented in 1.4.2 would be
disingenuous at best.  I may have strong opinions, but I won't play
mind games with you.

} 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.

     I think the suggestion I made of leaving the /etc files alone and
stashing a copy in /etc/orig would make adminstration easier and would
make the development of a merging tool easier.  Your current
/etc/default scheme would probably make the development of a merging
tool easier, but it does so at the cost of making administration
harder.  This is the wrong way to do things.

}-- End of excerpt from Luke Mewburn