Re: Git 2.18: RUNTIME_PREFIX... is it working?

[Jeff King <peff@peff.net>]

On Tue, Jul 10, 2018 at 12:13:42AM -0700, Perry Hutchison wrote:

> Jeff King <peff@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