PyECLib Packaging Party!

jerasure_issues.txt

1) Something got pissed off that installing "libjerasure2" hadn't installed the *.so file
   (that was in the -devel package)... might have been the plugin-loading code of liberasurecode?
   So in my packaging, I moved the "usr/lib/*/lib*.so"
   from debian/libjerasure-dev.install to debian/libjerasure2.install.  Oddly enough, the
   same thing is present in "gf-complete" package, but that never bit me...

2) I was building for Precise as well and I guess jerasure package wanted a newer automake
   than Precise shipped with.  So I had to package Trusty-version automake-1.14 and autoconf
   for Precise to use during building.  If the package /can/ be built successfully with Precise's
   version of automake, then relaxing that version requirement would make Precise package
   building less painful.

liberasurecode_issues.txt

1) I had to add an explicit dependency on "libjerasure2" in "liberasurecode/debian/control"
   in the "Package: liberasurecode1" section so that installing "liberasurecode1" would also
   install the necessary (for PyECLib, at least as currently written, I guess) package,
   libjerasure2.

PyECLib_issues.txt

1) I wanted the tools/pyeclib_*.py files installed as scripts, so I had to hack up the
   setup.py to add ```scripts=['tools/pyeclib_conf_tool.py', ...]```
   
2) Then I had to add shebang lines to the scripts or I got executable files packaged
   that got fed to bash when executed.
   
3) The library finding code in setup.py really sucks if you're relocating libraries
   at all (like we do, heavily, on CentOS/RHEL).  Our spec file really hacks up the
   upstream setup.py paths.
   
4) Having the upstream tarball expand out into a directory like
   ```kmgreen2-pyeclib-9b2ed408c1ff``` can be made to work, but is different than
   everything else that comes from, e.g., PyPi