[conspire] Breezy Badger -Tarballs

[Rick Moen]

Quoting John Andrews (jla1200 at netzero.net):

> My questions about compiling tarballs was probably just beginners curiosity 
> into doing something like that more than getting a package that will really 
> does something useful.

Well, your curiosity should be commended.

As people giving advice, we don't want to discourage that sort of
curiosity in any way -- even curiousity that carries some moderate risk
of getting yourself in trouble.  We tend to want to help you avoid
_unexpected_ trouble.  As to whether a particular resort to tarballs is
useful or necessary or desirable:  That's a judgement call.

I definitely would say:  Make sure you know what's available within your
distribution's package system (including, say, the build options Nick
pointed out), before resorting to an upstream tarball.

> Do you think that doing that (compiling odd non 
> debian/unbuntu packages) would damage my system?

Let's talk about that.  First, here's a footnote I appended to an article
printed in _Linux Gazette_  (http://linuxgazette.net/118/weatherwax.html#1):

  Rick Moen comments: While it's useful and worthwhile to know about a
  program's "upstream" development site, where (among other things) the
  author's latest source code can be downloaded, there are a few
  disadvantages that should be noted, (and some alternative locations that
  should be usually be preferred, instead, if such are findable):

  1. Absent extraordinary measures on your part, your Linux distribution's
  package-tracking system won't know about the program's presence on your
  system. Therefore, it won't know to avoid installing conflicting
  programs, removing libraries it depends on, etc.

  2. You won't get any tweaks and enhancements that may be normal (or
  necessary!) for applications on your Linux distribution -- unless you
  yourself implement them. You won't get security patches, either, except
  those written by the upstream author.

  3. Along those same lines, the desirable version to compile and run may
  well not be the author's latest release: Sometimes, authors are trying
  out new concepts, and improvements & old bugs fixed are outweighed by
  misfeatures & new bugs introduced.

  4. As a person downloading the upstream author's source code directly,
  you have to personally assume the burden of verifying that the tarball
  really is the author's work, and not that of (e.g.) a network intruder
  who cracked the download ftp site substituted a trojaned version.
  Although this concern applies mostly to software designed to run with
  elevated privilege, it's not a strictly academic risk: Linux-relevant
  codebases that have been (briefly) trojaned in this fashion, in recent
  years, on the upstream author's download sites, include Wietse Venema's
  TCP Wrappers (tcpd/libwrap), the util-linux package, sendmail, OpenSSH,
  and the Linux kernel (CVS gateway's archive, only). Unless you are
  prepared to meaningfully verify the author's cryptographic signature
  -- if any -- on that tarball, you risk sabotaging your system's security.

  All of the above are problems normally addressed (and the burden of
  solving them, shouldered) by Linux distributions' package maintainers,
  so that you won't have to. It's to your advantage to take advantage of
  that effort, if feasible. The memory of when a thousand Linux sysadmins,
  circa 1993, would need to do all of that work 999-times redundantly, is
  still fresh to us old-timers: We call those the Bad Old Days, given that
  today one expert package maintainer can instead do that task for a
  thousand sysadmins. And yes, sometimes there's nothing like such a
  package available, and you have no reasonable alternative but to grab
  upstream source tarballs -- but the disadvantages justify some pains to
  search for suitable packages, instead.

  Depending on your distribution, you may find that there are update
  packages available directly from the distribution's package updating
  utilities, or from ancillary, semi-official package archives (e.g., the
  Fedora Extras and "dag" repositories for Fedora/RH and similar
  distributions), or, failing that, third-party packages maintained by
  reputable outside parties, e.g., some of the Debian-and-compatible
  repositories registered at the apt-get.org and backports.org sites.
  Although those are certainly not unfailingly better than tarballs, I
  would say they're generally so.

  The smaller, less popular, and less dependency-ridden a package is, the
  more you might be tempted to use an upstream source tarball. For
  example, I use locally compiled versions of the Leafnode pre-2.0 betas
  to run my server's local NNTP newsgroups, because release-version
  packages simply lack that functionality altogether. On the other hand,
  that package's one dependency, the Perl PCRE library, I satisfy from my
  distribution's official packages, for all the reasons stated above.


The "build-dep" approch detailed up-thread should not be confused with 
the indented paragraph's discussion of upstream authors' tarballs.  The
former creates fully debianised (ubuntu-ised, etc.) binary packages,
applying distribution-specific patches automatically and using
particular upstream tarballs deemed of sufficient quality.


> There are already so many packages available and installed on my computer 
> that the non debian/ubuntu may be just a waste of time.

Well, if so, the good news is that you probably installed all that stuff
under /usr/local (or other non-system directory trees), where it's
segregated from the system, proper.  So, at worst, it's pretty easy to
clean out.

> I tried to start an account with Netflix but it would not let me access the 
> secure server from Mozilla. Oh well . I'll have to use windoze.

I have no specific knowledge of Netflix problems, and you haven't given
us enough data to help you.

Some sites attempt to guess your Web browser identity from its User
Agent string, and refuse to let you do various things if your User Agent
string isn't on the approved list.  Savvy Mozilla Navigator or Firefox 
users can get around that sort of simple block by _setting_ User Agent
to be something that's allowed in.  (With Firefox, you need to install
an add-in called User Agent Switcher, before you can do this.)

A few particularly clueless sites use genuinely Microsoft-dependent site
features, notably ActiveX.  I doubt very much that Netflix does:  That
sort of extremely clueless site behaviour is generally only imposed on
employees by (some) corporations having an all-Microsoft software
policy.