So, you provide ARM build. But you probably don't know that my NAS box runs OABI. No, you don't know, you can't know, and you shouldn't know. The only thing worth knowing is that writing great software in obscure and esoteric languages drastically limits its usage, impact, and collaboration around it. So, any idea of writing git-annex implementation in a sane, interpreted, "just works" language, e.g. Python? Thanks.
Good luck finding anything that works on OARM. Python itself does not support OABI:
(from http://bugs.python.org/issue1762561#msg158974)
Python on this system "just works". That's because Python is a project with a real community, so if one pundit said "not supported", dozen of people shrugged and typed "make", then packed up result for thousands to use.
But don't get carried away by OABI, that was just one random example how deployment of git-annex is problematic. There're bigger issues like community involvement, being able to investigate and resolve issues, submit patches, bring new working ideas, make git-annex development and lifecycle sustainable, in the end - as vividly cared by the author.
Sure, that's the plan. But first I'm doing my homework to understand how it got to that and how community copes with that. Maybe I don't get something and every open-source project should have a notice like: "Installation from scratch. This is not recommended." (http://git-annex.branchable.com/install/). Interested in building software you run? Interested to help? Get lost, you won't get it. Am I surprised? Nope, I'm doing my homework and know where that Haskell thing came from. A piece of Microsoft was largely involved with it, so no surprise of such attitudes.
Surely I'm not the only one who got jaundiced eye on git-annex: https://github.com/tv42/big : "big is not like git-annex, because: it's not written in Haskell, so it might even work across distribution upgrades and platforms". Certainly, stories of cvsup and unison, which are now where they should be - rest in peace, didn't help. So, once again, I'm interested to know how other people deal with this lack of proper compilation instructions, ability to get simple and easy tweaks, etc. - short of not using it, which seems to be a popular choice, despite all the git-annex coolness (I for one have been having its deployment in my queue fro half a year, instead of spending exactly a weekend to do tweaks I need and contribute them back).
I decided it was a bit harsh, so I removed comment. Here is how I solved problem:
I have a server without much storage which runs the git-annex process, the data is stored on the NAS mounted via iSCSI. I never even thought of trying to compile git-annex on a NAS. I did things like that many years ago and it used to much time, whether the language was, common or not, didn't change much. Missing floating point units on the NAS killed performance of the programms I wanted to run anyways.
There is too much negativity on this page, starting perhaps with its title.
The "this is not recommended" is not because we don't want people to build git-annex from source. It's to try to dissuade users who just want to get git-annex installed, and who would be scared off by a transient build failure, from building from source, when there are many builds provided by Linux distributions, etc that would be better choices for them to get started. Hopefully the new page and new wording gets this across better: "Experienced users should not find it too hard to build and install it from source."
If someone wants to reimplement git-annex, or parts of it, I think that the existing documentation (eg internals) should get them most of the way there.