On Sun, 3 Jun 2007 22:45:52 +0200
sean finney 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/.../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

Version: GnuPG v1.4.6 (GNU/Linux)