-
Simon McVittie authored
The PATH from outside the container doesn't really make sense inside the container, because the directory hierarchy could be totally different (particularly on unusual host systems like GoboLinux and Exherbo). Resetting it also makes sure we don't pick up local installations in ~/bin or ~/.local/bin, which could have dependencies that are unsatisfied in the container. Conversely, the PATH from the host might not include everything we need in the container. If the host system is an OS that only supports merged-/usr use, like Arch Linux, then it might not have both /usr/bin and /bin in the PATH - but if the container is not merged /usr, like a scout SDK sysroot, then we'll need both. This approximately matches Flatpak's behaviour: by default it resets PATH to /app/bin:/usr/bin (because it puts app-specific content in /app and can assume that its runtimes are always merged-/usr). Signed-off-by:
Simon McVittie <smcv@collabora.com>
Simon McVittie authoredThe PATH from outside the container doesn't really make sense inside the container, because the directory hierarchy could be totally different (particularly on unusual host systems like GoboLinux and Exherbo). Resetting it also makes sure we don't pick up local installations in ~/bin or ~/.local/bin, which could have dependencies that are unsatisfied in the container. Conversely, the PATH from the host might not include everything we need in the container. If the host system is an OS that only supports merged-/usr use, like Arch Linux, then it might not have both /usr/bin and /bin in the PATH - but if the container is not merged /usr, like a scout SDK sysroot, then we'll need both. This approximately matches Flatpak's behaviour: by default it resets PATH to /app/bin:/usr/bin (because it puts app-specific content in /app and can assume that its runtimes are always merged-/usr). Signed-off-by:
Simon McVittie <smcv@collabora.com>