Another tool for updating /etc -- lua||other script language
bikeshed
Robert Watson
rwatson at FreeBSD.org
Thu Mar 25 08:51:15 UTC 2010
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
More information about the freebsd-hackers
mailing list