On 11/30/16 at 11:51am, Allan McRae wrote:
On 30/11/16 01:58, Andrew Gregory wrote:
pacman's --root option is regularly (mis)used to use pacman to manage a mounted guest system, typically one whose pacman installation is currently broken. We have a few configuration defaults in place to make this sort of work, but support is incomplete. Those defaults only actually take effect if the settings haven't been set in a configuration file, several options still default to the host system resources, and using the guest's pacman configuration requires updating all configured paths to the new mounted location.
What use would the current --root option be after this is implemented? Is this just a bug that --root should already be working exactly like proposed new option?
The --root option merely specifies where package files are installed. That is not necessarily the root directory of a system. --root can't work like the new option because other configured paths can be outside it and it can't affect which configuration files are read because it can be specified in a configuration file. --sysroot would be a command-line-only option and all paths would have to exist under it.
Adding a --sysroot/--chroot option would allow pacman to properly operate in a mounted guest system. At the moment, there are two ways we could accomplish this: prefix all paths with the sysroot or just call chroot(2). Obviously, the problem with chroot(2) is that it requires special privileges. Unfortunately, I think my symbolic user/group patch (https://patchwork.archlinux.org/patch/3694/) will require chroot to work properly as I can't find any other way to look up users/groups in a mounted guest. So, we may have to implement both approaches so that regular users can perform queries but privileged users can perform transactions with proper symbolic name support.
Don't we already chroot when running the install scripts? Is this just a case of extending that chroot to the entire operation?
We do chroot for scripts and hooks, but we chroot to --root, which could be a subdirectory inside --sysroot. apg