On 19/12/16 00:53, Andrew Gregory wrote: > On 11/29/16 at 10:58am, 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. >> >> 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. > > How should --sysroot handle user-provided paths on the command-line? > Should they be treated as relative to --sysroot or the current root? > Assuming that at some point this will be implemented using chroot(2) > in at least some instances, all paths, including any package files > given to -U, *must* exist under --sysroot. So, even though I think > interpreting paths relative to the current root is more intuitive, it > means extra work for us to determine if the path is accessible under > --sysroot. >
My opinion with --sysroot, is that everything should be relative to the sysroot. As far as I can tell, that would be consistent with chroot, systemd-nspawn, etc. A
