Another tool for updating /etc -- lua||other script language bikeshed

[Robert Watson]

On Wed, 24 Mar 2010, Ivan Voras wrote:

> Wouldn't it be nice to have a "blessed" (i.e. present-in-base) script 
> language interpreter with a syntax that has evolved since the 1970-ies? 
> (with a side-glance to C that *has* evolved since the K&R style).
...
> As a possible alternative, or at least to learn about others' opinion on the 
> subject, I'd like to suggest Lua (http://www.lua.org/).

I think there are lots of good arguments for Lua in the base, but that 
etcmerge is definitely not one of them :-).  An important goals for a tool 
like etcmerge is a minimal dependency footprint, so that you can use it with 
all the existing versions of FreeBSD floating around and upgrade to new 
versions.  None of those existing versions have lua.  Good arguments for lua 
in the base might include:

- Moving to Lua as the scripting language for the boot loader
- Improving scripting capabilities in the installer

etcmerge sounds very exciting, especially for shops that want a more automated 
upgrade path.  It's easy to upgrade web browsers, and they're basically 
operating systems at this point, so it would be nice if we could offer FreeBSD 
upgrades with similar ease.

Quite a bit of our automated configuration update problem comes down to 
configuration file formats and the way diff/patch perform merges.  Consider 
files like inetd.conf, master.passwd, group, etc: they essentially ensure that 
there will be a conflict if you have any local changes and the vendor (us) 
makes an upstream change.  We used to have this problem with /etc/rc and 
/etc/rc.local, but rc.d has basically eliminated the problem by allowing 
boot-time custtomization through file insertion rather than file changes.

Choices made in the configuration design for launchd, xinetd, and others avoid 
this mistake.  Perhaps we shold be considering similar sorts of redesigns, 
focusing on how configuration files could be reworked to maximize automated 
update support.  Where there's a true semantic conflict, an update conflict 
requiring resolution is fine, but where there's no semantic conflict (i.e., we 
add _anotheruser to the base master.passwd), no upgrade conflict should arise.

(And definitely keeping this mind as we add new configuration files)

Robert