[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Why not move Apt to a relational database

On Sun, 3 Jun 2007 13:47:20 +0200
Christoph Haas <haas@debian.org> wrote:

> > What about embedded systems that can barely run sqlite?
> Is sqlite really *that* heavyweight?

No, that's why it is used in some embedded systems. Even so, it has no
place in the rootfs for an embedded system, IMHO. I'd rather not have
to repackage apt to remove this change. 

> Storing information about tens of
> thousands of packages in plain text files is surely not the best idea.

I think it's OK. Are there open bug reports arising from this method?

> Historically grown. Okay. But still worth to think about.

I disagree. Emdebian uses SQLite to store package data and just 1,000
packages takes 1.5Mb. The entire /var/lib/dpkg/available file on this
full Debian system is only 1.5Mb.

> > apt needs to be part of the debian-installer, why lumber the
> > installer with postgres or mysql or whatever?
> Nobody wants to use pgsql or mysql as a prerequisite to a base
> installation. Not the right tool for the job. Perhaps there is other
> software that is even more basic than sqlite but more basic.

There are two problems with changing the apt/dpkg data storage method:
absolute file sizes and package sizes. Text file storage leads to the
smallest combination of data file size and rootfs size.

> > That doesn't justify adding 10-20Mb of extra code to a rootfs -
> > especially when an Emdebian rootfs may need to be <5Mb in total.
> The current sqlite package is ~80 KB uncompressed. It I can imagine
> that the database might even be smaller and waste less inodes than
> what apt currently does.

The long descriptions appear to be the largest element.

> > Right mailing list but, IMHO, not a particularly good idea. Sorry.
> Right mailing list. Very good idea IMHO and right to the point. We
> just need a volunteer who knows enough about apt to make it use sqlite
> without breaking everything. Or do we have to wait until Ubuntu sends
> us a patch? ;)

I still disagree - I see no need for the change. The other problems
identified by Joey also apply to sqlite:

 - using an RDB requires a running RDBMS
 - running an RDBMS requires memory and cpu usage
 - in case of an upgrade RDBMSs often dump there databases and import
   them.  What will happen when the upgrade fails during this?  No
   package database would be really bad
 - copying parts of the database to another system, or patching it
   is not as easy as it is with plain files

> When I complained about the slow package database (it turned out to be
> that that many files on ext3 make reading the package cache take
> longer than formatting a floppy disc on a 1541) someone pointed to:
> http://people.debian.org/~seanius/dpkg-sqlite/

Umm, that uses python to create the database - if there are problems
putting sqlite into a rootfs, there is NO place for python!! Emdebian
is removing perl from essential, let alone python (and replacing bash
with dash/busybox too).


Neil Williams

Attachment: pgpAWRN6DK3uV.pgp
Description: PGP signature

Reply to: