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

[Daniel Jacques <dnj@google.com>]

Perry Hutchison wrote:

> 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.

Yep. The code also allows for use of "argv[0]", but that has its own set of
problems. These were previously covered in the discussions leading up to
the patch landing, but to summarize, "argv[0]" can be completely manipulated
by the calling process, whimsically or in response to constraints such as
links, and is wholly unreliable for self-location.

Other kernels have their own behaviors with respect to path self-location,
and none seem to be straightforward. This link seems to have a good
rundown of the details and differences:

https://stackoverflow.com/questions/1023306/finding-current-executables-path-without-proc-self-exe

All things considered, I think executable path self-location is markedly more
fragile than using static paths, both with increased dependencies and added
inconsistent behavior and limitations, and should not be the default
on any platform.

Both Johannes' original RUNTIME_PREFIX implementation for Windows and the
Linux/etc. expansions that I did were written to serve constrained special case
deployments. In that capacity, they can be really useful, as the fragility is
managed by their respective environments.

My particular use case served the purpose of building Git once and deploying
it via archive on other systems. This capability requires the additional work of
building portable versions of Git's dependencies and their associated
resources, and statically linking everything together.

This is a lot more portability than the conventional user requires, and also
necessitates a significantly more complex build process. However, making Git
itself portable via RUNTIME_PREFIX without similar work on its dependencies
limits the usefulness of that portability, since it's still bound to
the system's
libraries and their resources.

Cheers,
-Dan