Support alpm/pacman package manager #45

Hello there!

I'd like to use chunkah to chunk my Arch Linux-based bootc base images. I already had a look at the source code and I think I'd be able to contribute a ComponentsRepo implementation for this. I already thought a bit about this and would be interested in your opinions on a few challenges that an alpm backend would bring along:

1. First of all: Would that be interesting for the project and would you merge it?
2. I had a look at the rpm repo and saw that is uses quite a few helper functions for path canonicalization that look pretty generic and useful for any kind of Repo based on a package database. Would it be possible to extract them and make them pub/callable by other component repos?
3. What would be the minimal test coverage needed? Unfortunately, alpm seems pretty hard to write tests for as you can only initialize a repo by providing filesystem paths as Vec<u8>... Of course, one could provide a "real" package database consisting of packages from base. I had a quick look at that and found that it is already 14M which seems too large to commit into a git repo. Any ideas are appreciated!
4. Unfortunately, alpm neither provides (useful) changelogs nor (very useful) file info, i.e. most packages don't have any changelog entries and package contents are returned as a list of paths (always including all parents, which means that pretty much every installed package claims /usr for example). There's also no way to differentiate between files, directories, symlinks, etc. As such, it would probably be useful to be able to enrich this data somehow. For example, one could externally maintain a list of changelogs generated from the git commit log of the corresponding PKGBUILD repositories at gitlab.archlinux.org, possibly aggregated by only providing a stability score derived from that information. Where would you draw the line for this project? Would, for example, a command line flag to provide some extra data to a ComponentsRepo implementation already go too far? What about a mapping from package name to a precalculated stability score?

Another approach I have thought about was to externally maintain a alpm->package info tool which could return a JSON-encoded list of something along the lines of rpm_qa::Package.