On Sun, 3 Jun 2007 22:45:52 +0200 sean finney <seanius@debian.org> wrote: > On Sunday 03 June 2007 21:30:26 Josselin Mouette wrote: > > Even if SQLite is more robust than Berkeley DB, I don't think you > > could recover anything from a corrupt database. Plain text will > > always turn out better in terms of disaster recovery. If > > performance is an issue, a text file can - just like a bdb file - > > be indexed. Corrupt indexes can be regenerated, but corrupt > > databases cannot. > > i believe that i also stated in my last posting to dpkg-devel that a > good implementation would treat such a "db" as cache, and handle them > being corrupted/deleted: > > http://lists.debian.org/debian-dpkg/2007/04/msg00015.html I like the idea that the flat files remain and that the db is "just a cache". It would be fine if this cache is "disposable" in that way because it does solve the issues of corruption, upgrade paths etc. To me, the best solution would be for an option in /etc/apt/apt.conf (or similar) to enable and disable the sqlite cache. This would solve my problems because I could disable the sqlite during the initial stages and only enable it if the system has sufficient resources to run sqlite almost constantly during the rest of the installation. My problem is with trying to replace the flat files with any kind of database - I believe that the flat files should always exist on every system and a disposable cache (just like the apt-cache) suits this usage quite well. -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
pgpF2QXtoA9hP.pgp
Description: PGP signature