RE: Why don't we symlink libexec/git-core/* to bin/git?
- From
Randall S. Becker <rsbecker@nexbridge.com>
- Date
- Mar 13, 2018, 19:32 UTC
- Message-ID
- <003d01d3bb02$076aba00$16402e00$@nexbridge.com>
- In-Reply-To
- <xmqqfu533jrk.fsf@gitster-ct.c.googlers.com>
On March 13, 2018 2:37 PM, Junio C Hamano wrote:
Show 18 quoted lines
> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes: > > > Related to this, I came across this bug report > > https://gitlab.com/gitlab-org/omnibus-gitlab/issues/3265 which is > > wondering why we're installing N copies of the git binary, presumably > > they're building with NO_INSTALL_HARDLINKS. > > ... > > But is there any reason anyone can think of for why we shouldn't be > > figuring out the relative path and symlinking the two? > > > There is no fundamental reason not to offer such an "install" method as an > option; unless you count a more philosophical aversion to use symlinks due > to (perceived) additional fragility, that is. > > The resulting code may become messier than without, but as long as it is > without the reasonable range for usual price we would pay for a new > "feature", that would be tolerable, I guess.
A possible (remote) reason for not doing this is in environments using ACLs that somehow want different access permissions on some functions vs. others AND where the platform does not have the ability to separately secure links vs. objects. I don't know of such an environment, but you never know. I know it's a stretch, but I can see security-types being worried about this. I do know of environments where /usr/local/lib is secured differently from /usr/local/bin to prevent inappropriate .so loads on a selective basis, so there's that. Again, this is a stretch. As long as we continue to have a method of forcing the expensive way for the paranoidly inclined ;) -- not meaning offence to those, of course.
Cheers, Randall
-- Brief whoami: NonStop developer since approximately 211288444200000000 UNIX developer since approximately 421664400 -- In my real life, I talk too much.