[conspire] Thank you

[Rick Moen]

Quoting Ross Bernheim (rossbernheim at speakeasy.net):

> I want to thank Christian and Rick for helping me get repsnapper 
> to compile and run under Mint.

When Ross called me over, he was trying to work through the Readme.txt
file provided inside the RepSnapper source tarball.  (RepSnapper is
controller software for the RepRap 3D printer.)

It turns out that the build (compilation) instructions in the Readme.txt
are somewhat halfassed and incomplete.  A brief search turned up the
full instructions online:
https://github.com/timschmidt/repsnapper/blob/master/doc/manual.asciidoc

So, there were some tools and libs Ross needed for compiling RepSnapper,
and I'll detail that, but first a few words about a more important
matter, software sourcing.

It happens all the time:  You hear about a piece of software that might
be handy, and a quick check suggests it wasn't installed as part of your
Linux distribution's default (or whatever) installation.  You Web-search
its name, and find the developer site where you can download a .tar.gz
('tarball') source code archive.  Or perhaps you see instructions for
equivalently checking out the package's source code from CVS, or svn, or
git.

It's natural to charge right ahead and compile the software from source
code in accordance with the developer's instructions.  However, that's
exactly when you should take a break and rethink the matter.

Many people are unaware of the benefits they typically enjoy from using
already packaged, compile, software from their distributions' package
maintainers, who in the jargon are called 'downstream' software
sources, where the developers are deemed 'upstream'.  The package
maintainer does (or should do) quality control for you, for starters.
It's the maintainer's job to ensure that distro users don't get
halfbaked betas.  The package maintainer also takes on the job of
vetting that the upstream source code he/she adopts for packaging is
genuine, i.e., gpg-signed by the upstream developer's real key, thus 
protecting you against forgeries inserted on compromised hosting sites.
The latter is a real concern:  See
http://linuxmafia.com/~rick/faq/index.php?page=virus, several paragraphs
starting with the words 'Three objections', where I detail seven
examples of that happening at upstream ftp sites.  In all cases, no
distro maintainers were fooled.

Also, the fact that the distro-packaged versions are _maintained_ means
you will get updates through distro maintenance channels.  If you
compile from source, updates happen only if/when you remember to update
manually.  Also, it's regrettable that your distro package tools won't
know that the locally compiled software is even there, so you can't get
the benefit of automatic dependency management, let alone remove
software with a single package command.

So, in short, locally compiling packages from source tarballs should be
avoided if there's any sign of a reasonable alternative.

Ross and I took a break from the compiling to look around for such an
alternative.  

Ross runs Linux Mint's main (GNOME) edition, which is Ubuntu with some
extra stuff.  Ubuntu uses Debian-style .deb packages.  So, obvious
searches to find .deb packages compatible with Ubuntu were:

   repsnapper ubuntu

   repsnapper deb

In Mint itself, Ross could search the available distro packages by
doing:

   sudo apt-cache search repsnapper

That does a full-text search of Mint's local database on available
packages.  _Or_, Ross can use Mint's online package search engine:
http://packages.linuxmint.com/

(Note:  'sudo apt-file search repsnapper' would match against only
_filenames_ in available packages; 'sudo apt-cache search repsnapper' 
searches package name, filenames and the long description of packages.)

Ross had basically already done that, so the _best_ type of packages 
(maintained distro packages) had already been ruled out.  Web-searching
for 'repsnapper deb' and 'repsnapper ubuntu' allowed essentially ruling
out the second-best option, a third-party .deb repository of repsnapper
packages compatible with Ubuntu/Mint.  No such luck.

The third-best alternative would be a locally compiled package done
Debian-style, producing a binary .deb at the end of compilation.  We
checked in the repsnapper tarball to see if there were a 'debian/'
subdirectory with a 'rules' file in it.  No luck.

Given a debian/rules subtree, compiling a deb is trivial.  Here's one of
many write-ups about how:
http://carlo17.home.xs4all.nl/howto/debian.html

The fourth-best option is a plain ol' non-Debianised compilation and
installation into /usr/local/ , which is what we did.  Tools exist to
write a debian/rules tree for you, notably Joey Hess's novice-friendly
debhelper tool.  However, we were in a hurry and didn't bother.



About the stuff that Ross's system was missing that needed to be
retrofitted before we could compile repsnapper:  It wasn't exactly
surprising, but Linux Mint includes roughly none of the tools needed to
compile software, because it's targeted at the Ubuntu crowd of desktop
users, who are assumed to be not interested.

Before we found
https://github.com/timschmidt/repsnapper/blob/master/doc/manual.asciidoc
, the real build instructions, and while still assuming that Readme.txt 
was all we had, I had just followed Readme.txt's first two steps:

  ./autogen.sh
  make

Each time 'make' (the compile step) failed on a missing dependency, I
just Web-searched its name and installed the related Mint / Ubuntu 
package via 'aptitude install [packagename]'.  I think that got us
through build-essential automake intltool libtool .  The compile finally
worked, and then we realised that Readme.txt lacked some obvious steps,
and so looked around and found the other, real instructions.