Adding Concord to package managers

[StefenSharkey]

And @lcsmuller said, "let there be Concord."

However, what he didn't say was "let there be package manager support."

Ever since Concord started, users were required to semi-manually install and update it. Whether the update was to a different release or commit, the process was the same. They were trivial instructions to follow, but they came with two main pitfalls:

1. What if Concord's dependencies changed? e.g. libraries and versions
2. What if Concord's environment setup changed? e.g. GCC flags

If users weren't diligent on updating Concord and reading the README when those types of changes were made, they could find themselves unable to update Concord. Worse yet, they might have a compiling, but broken, installation of Concord.

It's uncommon, especially for Linux users, to not use their package manager to check for updates on a semi-regular basis. Thus, I propose that we add Concord to different package managers (Aptitude, Portage, Pacman, etc.). Concord has matured enough, and has a large-enough userbase, that this is a logical step to take. Advantages to Concord being in official package managers are:

1. Users may search for packages in their package manager, see Concord, and gain interest.
2. It reduces a soft dependency on Git.
3. If a precompiled build is available in the package manager, it reduces most, if not all, build-only dependencies. Note: this will almost never be the case for package managers that encourage or require packages to be built from source, such as AUR or Portage.
4. Non-contributing users will no longer need to manually go through the process of installing and updating Concord via Git.
5. Upon a new Concord release, users will be able to use the same set of commands they use for updating any other package or library on their system.
6. If dependencies or environment setups (within Concord's control) change, the package manager will handle that.
7. If a sacrilegious user wishes to commit blasphemy by uninstalling Concord, the package manager will handle that.

With all this said, this does require enough buy-in from Concord's maintainers, contributors, and users for it to be considered a worthwhile endeavor, as some package managers have strict rules on allowed packages, release frequency, stability, etc. If there is enough buy-in, a plan of action should be developed; none will be developed at this time.

React to this with 👍 or 👎 if you wish to see this or not. Discussion is encouraged, especially if you do not wish to see this.

[HackerSmacker]

I am definitely buying in here, there's no reason to not. I propose this:

Starting with the next release cycle, Concord can make its debut on a variety of package managers. Two days after every release, the packages will be marked out-of-date and be updated.

However, there is a big issue. A lot of those Linux distro guys will compile the same package for a variety of CPUs, but, thanks to a withstanding bug in the cURL websocket interface code, we cannot run this on big-endian machines. So, if Debian (or whoever) goes and builds Concord for a SPARC or System Z (or any other big-endian machine), users will not be very pleased with a totally busted package. So, we'd need to definitely need to (for the time being) exclude packages from certain CPU architectures; the common ones that people actually use (like x86 and ARM) work fine, the more obscure ones do not (although, to be fair, I might be the only one that cares to run Concord on a System Z box).

Once all of that is sorted out and extensive testing (or possible rewriting) of the CWS code, we should be good to roll Concord on big-endian machines too.

Also, I don't think we should limit ourselves to Linux here at all; Concord works on (Free,Net,Open,DragonFly)BSD, Cygwin, and a few other odds and ends perfectly. I can handle submitting a FreeBSD port sometime later.