On 01/13/2011 12:12 PM, C Anthony Risinger wrote: > leverage a revisioning system for package files instead of tarballs, > even if only locally. store metadata in a non-relational engine like > couchdb (peer replicaition), or at least something like sqlite, for > sane access. A relational engine is actually really helpful for packages. A while ago I tried writing a package manager like pacman but using sqlite, and it's MUCH faster and still easy to use. The huge pauses every time you need metadata are incredibly annoying, and they completely disappear when you store things in a real database. The problem is that it has to be used by the official package manager, because having package data stored in two formats causes issues (because any time you use pacman, the other database doesn't know what changed). Revisioning package files is also interesting; I don't see the point of doing it locally though. Once you have the package, installing it is fast. Checking if files are the same first seems like a waste of effort. There already is a mechanism for creating those .pacnew files (and I think auto-merging those into the existing file would mess with the "knowing what your system is doing" part of Arch). Using deltas for packages would be helpful though, especially in the case of huge packages with minor changes. The rest of your changes sound like things that would make packaging harder, and you should know that some (most?) of us like Arch's packages because they're easy to make. It make seem overly simple, but that's exactly what I want out of a package: Give a name, version number, source, and dependencies, then the commands I'd use to build it, and I'm done. If Arch every became like Debian with it's fancy, huge-time-sink packaging, I'd find a different distro.
