[pacman-dev] [RFC] adding a --sysroot option
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. apg
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?
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? Allan
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
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. apg
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
--root is not sufficient to properly operate on a mounted guest system.
Using --root still uses the host system's configuration and there is no
way to correctly use the guest configuration without manually modifying
any Include directives. --sysroot provides an easier way to operate on
a guest system by chrooting immediately after option parsing before
configuration parsing or performing any operations. It is currently
limited to the root user, but that's enough for restoring a guest system
to a working state, which is the primary intended use case.
Signed-off-by: Andrew Gregory
participants (2)
-
Allan McRae
-
Andrew Gregory