From owner-freebsd-hackers@FreeBSD.ORG Sat May 12 13:11:27 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A7B6316A409 for ; Sat, 12 May 2007 13:11:27 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (c220-239-3-125.belrs4.nsw.optusnet.com.au [220.239.3.125]) by mx1.freebsd.org (Postfix) with ESMTP id 1E6B313C469 for ; Sat, 12 May 2007 13:11:26 +0000 (UTC) (envelope-from peterjeremy@optushome.com.au) Received: from turion.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by turion.vk2pj.dyndns.org (8.14.1/8.14.1) with ESMTP id l4CDBP4t015921; Sat, 12 May 2007 23:11:25 +1000 (EST) (envelope-from peter@turion.vk2pj.dyndns.org) Received: (from peter@localhost) by turion.vk2pj.dyndns.org (8.14.1/8.14.1/Submit) id l4CDBOIX015770; Sat, 12 May 2007 23:11:24 +1000 (EST) (envelope-from peter) Date: Sat, 12 May 2007 23:11:24 +1000 From: Peter Jeremy To: Michel Talon Message-ID: <20070512131124.GK10647@turion.vk2pj.dyndns.org> References: <20070512004209.GA12218@lpthe.jussieu.fr> <17989.8202.624522.136573@bhuda.mired.org> <20070512090935.GA13929@lpthe.jussieu.fr> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="17/8oYur5Y32USnW" Content-Disposition: inline In-Reply-To: <20070512090935.GA13929@lpthe.jussieu.fr> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.14 (2007-02-12) Cc: freebsd-hackers@freebsd.org, Mike Meyer Subject: Re: DPS Initial Ideas 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: Sat, 12 May 2007 13:11:27 -0000 --17/8oYur5Y32USnW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2007-May-12 11:09:35 +0200, Michel Talon wrote: >- first i don't suppose sqlite3 is busted, since i suppose it is in the > base system and it works by definition. It can happen that base system utilities become unusable for various reasons: Maybe an installworld went wrong, maybe someone accidently deleted a shared library, maybe the disk developed an inconvenient bad sector. If sqlite3 is being used solely for ports management then it may be a reasonable assumption that sqlite3 is always working but if (as has been suggested) SQLite is used for base system config files then it is essential that those files be repairable. > Your hypothesis is alike, what >do i do to edit my config files if vi and ed are busted? Use emacs :-) Seriously, you can probably get away with sh builtins for most purposes: while read line do case "$line" in foo*) echo bar ;; *) echo "$line" ;; esac done < file > file.tmp mv file.tmp file > Moreover if >sqlite3 gets really busted i can import a copy and hope it works, I agree that sqlite3 is good in this respect. "Import" implies that you are able to get the system to a point where it can communicate externally without needing whatever tool is broken. >- second, if i am sql allergic, it takes one command to export the table > to a straight file, This is only usable if the schema is designed so that the tables are reasonably independent. It's certainly possible to design something that could not be usefully exported table-by-table and edited. >- is the cost of including sqlite in the base system so high that =20 >the above benefits are insufficient? Personnally i don't know, but i >think some discussion is at least in order. I agree that this topic is worth discussing. There is a very high bar for including new utilities in the base system because every time a new utility is added, the maintenance effort goes up. So far I haven't seen anything that would make me say "SQLite should be imported". >- and finally to answer one of Bill's critiques, why sqlite rather than=20 >a Berkeley database? Precisely because sqlite offer a lot of facilities=20 >that Berkeley db doesn't offer, such as export and import to and from=20 >csv files, This is a function of sqlite3(1) rather than the SQLite database itself. It wouldn't be that difficult to write a tool to convert a BDB into a flat file of key,value pairs. > auto documentation of the table contents, This is a big plus for SQL. > while it requires >in fact programming and knowledge of the api of the database to hand >edit the Berkeley db. Very trivial effort - if we had a need for it, someone could write the necessary few dozen lines and commit it. The downside is that since BDB isn't self documenting, a flat file may not be any use. --=20 Peter Jeremy --17/8oYur5Y32USnW Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGRbz8/opHv/APuIcRArL0AKCPiCls9zKufdAnHUMW1otohm6LJACeKA16 YFJS0ZbyuI+1nnAZK0Ql7v4= =11L+ -----END PGP SIGNATURE----- --17/8oYur5Y32USnW--