Add UI helpers to .deb package & change install location w/ symlinking

[vdye]

Fixes #387

Changes

• Add Atlassian.Bitbucket.UI and GitHub.UI to created .deb package
• Move the binary install location to /usr/local/bin/share/gcm-core, with symlinks in the original location (/usr/bin)

Questions

• Is /usr/local/bin/share/gcm-core the right install directory to use?
  • Answer: use /usr/local/share/gcm-core, symlinked to /usr/local/bin
• Right now the symlinks are relative paths (see here) - should they be absolute path links instead?

[vdye]

I'm not sure why the build failed - the only changes in this pull request are for Packaging.Linux, so it shouldn't affect the Mac test execution (link to test failure). Is this a test that occasionally fails, or is this change interacting with the tests somehow?

[mjcheetham]

Is this a test that occasionally fails, or is this change interacting with the tests somehow?

I've not seen this failure in CI before, but I've heard of the same underlying issue affecting some customers who use the Keychain from other C# projects, but only sporadically.

[mjcheetham]

@vdye I've pushed a commit (1cefe59) that should help side-step the flakey Keychain test for macOS. If you rebase this work on the latest main branch, you should be good!

[mjcheetham]

Is /usr/local/bin/share/gcm-core the right install directory to use?

We had a similar question when first putting the Linux support in: to use /usr or /usr/local. In the end we opted for /usr (even though on macOS we're using /usr/local).

See https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04.html

Re-reading the FHS I'd argue that /usr/local should be the correct place, and we're currently placing bits in the wrong place:

4.9.1. Purpose
The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated. It may be used for programs and data that are shareable amongst a group of hosts, but not found in /usr.

Locally installed software must be placed within /usr/local rather than /usr unless it is being installed to replace or upgrade software in /usr.

Thoughts @derrickstolee @jeffhostetler @dscho ?

[derrickstolee]

Re-reading the FHS I'd argue that /usr/local should be the correct place, and we're currently placing bits in the wrong place:

4.9.1. Purpose
The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated. It may be used for programs and data that are shareable amongst a group of hosts, but not found in /usr.
Locally installed software must be placed within /usr/local rather than /usr unless it is being installed to replace or upgrade software in /usr.

I agree that /usr/local/ is the right place. That's where we put microsoft/git on install, too.

The biggest question is: how do we get users who currently have it in /usr out of their current state? /usr might take priority, so if we simply start adding it to /usr/local we will have those users stuck on an older version. (Right?)

[mjcheetham]

/usr might take priority, so if we simply start adding it to /usr/local we will have those users stuck on an older version. (Right?)

I believe you'd want /usr/local to take priority over /usr. Logically your local install should take precedence over any distribution binaries, no (hence why we put microsoft/git there)?

I know on macOS the default PATH is /usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin.

In lieu of more concrete defaults docs, here's my findings of default PATH values for various distros:

Distribution	Version	Default PATH
Alpine	3.14	/sbin:/usr/sbin:/bin:/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
CentOS	8	/home/$USER/.local/bin:/home/$USER/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin
openSUSE	Leap 15	/home/$USER/bin:/usr/local/bin:/usr/bin:/bin
Ubuntu	18.04	/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin

Using the getconf tool on Ubuntu 18.04 however you get this:

> getconf PATH
/bin:/usr/bin

..which is the opposite, and doesn't list local at all(!)

[jeffhostetler]

On my Mac:

$ getconf PATH
/usr/bin:/bin:/usr/sbin:/sbin

whereas my $PATH has (somehow) accumulated /usr/local/bin.

[mjcheetham]

whereas my $PATH has (somehow) accumulated /usr/local/bin.

Mac has the path_helper tool and its additional way of setting up the PATH.

I really don't think there is anything akin to an default ordering, defacto or otherwise. 😢

[mjcheetham]