On Tue, Jul 10, 2018 at 12:13:42AM -0700, Perry Hutchison wrote: > Jeff King <p...@peff.net> wrote: > > > If I understand correctly, the Linux implementation requires reading > > from /proc. So an executable that only did RUNTIME_PREFIX (with no > > fallback to static paths) would be unhappy inside a chroot or other > > container that didn't mount /proc. > > If we need /proc, wouldn't we _already_ be unhappy inside a chroot > that didn't mount /proc, even _with_ fallback to static paths? > Last I knew, the whole point of chroots/containers/jails/etc. was to > prevent access, from a process running inside the container, to any > part of the FS that's outside of the container.
My point is that aside from RUNTIME_PREFIX, we don't need /proc. So somebody who currently builds Git with a static path like "/usr/libexec/git-core" and runs it inside a chroot will be just fine as long as /usr/libexec/git-core is available at that name inside the chroot. But if the build starts relying on RUNTIME_PREFIX, it's going to regress their case. I'm not sure how hypothetical this is. A lot of Debian tools use chroots to build packages for specific releases by basically installing the distro inside the chroot. I don't know whether /proc is available in those chroots or not. If not, then I suspect builds that rely on installing Git inside the chroot are going to break. +cc Jonathan, who maintains the Git package for Debian, and can probably say immediately whether I am way off base. ;) -Peff
