Package Manager

[jhuntwork]

This is a long term feature request

pacman works great, is lightweight, and has a lot of really nice features. It's served this project well, really helping it to focus on some of the more important things first.

But there are a few things about it I'm not so fond of:

Its heavy reliance on bash scripts for building

The PKGBUILD format is actually really nice and easy to understand as a set of build instructions. It's basically just bash variables, arrays and functions. And so it makes sense that the tool that uses it, drives the building, would also understand bash. However, as much I like writing shell scripts for their immediacy and appearance of portability, they are fragile. I generally agree with the sentiments in Rich’s sh (POSIX shell) tricks, notably:

I ... consider programming sh for any purpose other than as a super-portable, lowest-common-denominator platform for build or bootstrap scripts and the like, as an extremely misguided endeavor

The makepkg tool itself and all of its libs make up a full suite of bash that would be nice to replace with code that doesn't suffer from the same issues, something that can be truly unit tested, for example.

Its strong dependency on gpg for package and repository signing

Surprisingly, it looks like pacman (or maybe it's gpgme) shells out to to the gpg binary to do validation of packages. If only the gpg binary is removed from the system, pacman cannot validate signed packages.

Originally posted by @jhuntwork in #7 (comment)

I believe a package manager should be able to directly support digital signatures and verification without requiring the entire heavy gpg implementation on a running system. As of now, gpg appears to be the only signing tool that is supported by pacman.

Its user interface

I've used pacman for a while now, and so have started to get used to its short flags for nearly everything. However, even today there will be a specific feature I'm looking for and have trouble finding it. For example, looking up information on what packages are available to install, seems like it should be under -Q, --query, but that only works on things in the local system. To understand what the remote offers, you have to do -S, --sync. Also, if you want to know what package owns a file installed on the local file system, you can run pacman -Qo [file], but if you want to know what package provides a file or lib (local or remote) you have to do pacman -F [file]. There is a sort of sense there, once you are used to it, but I believe it isn't easy for new users to navigate the CLI options to find the action they are looking for.

I'm not decided yet on what direction should be taken, but my thought is to start by replacing makepkg, having it produce pacman compatible packages, and work from there in a sort of strangler pattern until pacman is fully replaced.

Again, this is a long-term feature request. Nothing with pacman is changing for the moment. Input, suggestions, ideas here very welcome.