Neil Williams <[EMAIL PROTECTED]> writes: > On Sun, 03 Jun 2007 21:50:24 +0100 > Roger Leigh <[EMAIL PROTECTED]> wrote: > >> > 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. >> >> Why would it need to be on the root? Surely the binaries and data >> would just go on /usr and /var as normal? > > ? A rootfs is the base filesystem created for the installer and for > test environments like chroot.
OK. >> Perhaps just using sqlite as an (optional) cache for dpkg and/or apt >> would bring sufficient improvements to systems which desire it > > That could actually be quite difficult - how would you migrate from one > to the other? If the database is "just a cache", then it should get transparently rebuilt as soon as you change it. > The installer will inevitably use the smallest possible combination > of packages, the finished installation might need to use > sqlite. Besides, you still have the same problems of trying to copy > package sets and having to run sqlite before anything else can be > done. If it's an optional cache, then there's no need to actually build the cache if it's not possible; you can just fall back to the real data. > Migrating from a busybox rootfs (without dpkg) would potentially cause > more problems and making busybox depend on sqlite is plain crazy. Sorry, but I fail to see the connection between busybox and sqlite. If enabled, sqlite would be part of dpkg, probably either statically linked or dynamically loaded. I would think static, for safety. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
pgpZ4v1UNWvZq.pgp
Description: PGP signature
