[arch-general] Ye Olde Package Manager

Brendan Long korin43 at gmail.com
Sat Jan 15 16:34:47 EST 2011


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.


More information about the arch-general mailing list