I was really happy to find this post today as I have wanted to use pacman for user package installs in the past and came back to this problem today. William, did you take this idea any further? I'll try to flesh out a use-case in case it helps. I am not an expert user of makepkg or pacman. I'm looking for a package manager to use on a multi-user system for user installable libraries and software. (eg the RootDir would be ~/.local, and the repo cache and database would be in the users /home path). Implicit is that the repo database is unique to that user (on an Archlinux system there would also be the normal system repo database). I have a large number of users, all developing a complex software. To partition and synchronize the work, the software is broken into a number of library and binary packages. The package manager (pacman for the purposes of the rest of the discussion) would speed and ease installation of (project specific) dependencies. Since version dependencies are handled by pacman, the build tools don't have to worry if the correct versions of each library are installed. Deployment to existing developers and setting up new developers is fast and deployment in the field is the same. Beyond the root user permissions issue that william tackled, there is the issue that we have two domains of dependencies (system and user). At some point the user repo will need to know that the system fulfills some of it's dependencies. Where I to grab williams patch and just start hacking, my approach would be to manually generate a set of dummy packages that are empty but 'provide' the system installed packages (an empty glibc package for instance). A pre-install script to verify that the package is actually installed at the system level would probably be desirable. I believe the above approach would work, letting the two package repos do their jobs. However it's labor intensive to fill in the interface layer of packages needed by the user repo. Having the user repo database cascade to the system repo database would be even better (first check for a dependency in the user repo database, and if it's not available there, check the system repo database. If in the system, dump the system package list to the terminal so the user can either install via sudo or send a request to the administrator.) Does that make sense? -Hauptmech
The database directory should only ever be writeable by root. It would be a major security issue otherwise (particularly as one promenant distribution can still not sign databases...). So how would a user of "--noroot" add a database? If we are restricting them to -U, there is no need for makepkg support. It's a security issue if the database directory for a system is writeable by a non-root user, however the point of this is to allow makepkg and pacman to be used for non-system applications, similar to the way that pip can be used in a virtualenv. You would set RootDir to somewhere that you have write access to (/home/wgiokas/foo) and, get it set up for pacman (add the directories it needs) and then run it with --noroot. Pacman is going to error itself now if it can't write files.
In conclusion, I'd like to see a very well thought out plan discussed before I look at code for this. Alright, I'll keep working on stuff. Thanks for the feedback, though. There's still a whole lot more that I've found that needs to be changed to use this to extract and work with packages as a non-root user.
Thanks,