From owner-freebsd-hackers@FreeBSD.ORG Thu Mar 25 08:51:15 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 00D6A1065670; Thu, 25 Mar 2010 08:51:15 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id CFA548FC1F; Thu, 25 Mar 2010 08:51:14 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 5DB1846B53; Thu, 25 Mar 2010 04:51:14 -0400 (EDT) Date: Thu, 25 Mar 2010 08:51:14 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Ivan Voras In-Reply-To: Message-ID: References: <201003231108.45102.jhb@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-hackers@freebsd.org Subject: Re: Another tool for updating /etc -- lua||other script language bikeshed X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Mar 2010 08:51:15 -0000 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