Date: Thu, 25 Mar 2010 08:51:14 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Ivan Voras <ivoras@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: Another tool for updating /etc -- lua||other script language bikeshed Message-ID: <alpine.BSF.2.00.1003250842520.14365@fledge.watson.org> In-Reply-To: <hod31p$qlc$1@dough.gmane.org> References: <201003231108.45102.jhb@freebsd.org> <hod31p$qlc$1@dough.gmane.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1003250842520.14365>