[TriLUG] package management pitfalls

[Brandon Van Every]

On Mon, Oct 29, 2012 at 10:16 PM, Igor Partola <igor at igorpartola.com> wrote:
> For me the killer feature in the Linux world is the package manager. Even
> OS X doesn't IMHO have this ease of use. I'll give you two examples:
>
> Example 1: A few years ago, when both my wife and I were in school, she had
> to do some work with molecule modeling for an advanced chemistry class. The
> professor printed out two pages of instructions on how to get a project
> called PyMOL to work. She got lost about half way into the first page and
> asked for my help. I ran $ apt-get install pymol on my Ubuntu box and about
> 3 minutes later she was using it. Mind you, she was an avid Windows user up
> to that point and did not want anything to do with Linux. That day she
> became a convert.

I would like to warn the unwary that packages on Linux aren't entirely
a pile of roses.  Packages work well when they're coming from A
RELIABLE REPOSITORY, are applications rather than system components,
and you don't need the latest greatest of anything that open source
has to offer.  If you violate these assumptions, you can get into hot
water real fast.  Packages will pull in dependent packages, and if
you're pulling in a lot of system components from an unreliable / not
thoroughly tested repository, it can definitely render your system
non-functional.  There are elaborate deep learning curve rituals for
trying to get more of a handle on package repositories, such as "app
pinning" and piles of other mumbo jumbo.  It's unreliable, dangerous,
and I've learned to never authorize a "testing" or "experimental"
repository on a production system, lest I lose it.  I also won't
authorize any third party repository if they're offering system
components, as it's very unlikely those components will have been
tested sufficiently and will probably make things go belly up.

Packages are like, "Wow, I can get all this stuff easily installed on
my computer!"  But you don't *want* all that stuff easily installed on
your computer....

Another minor issue is what I call "package paranoia."  If you need
the latest greatest release of some piece of open source software,
there probably isn't any package for it yet.  Or if there is, it's in
an experimental or testing repository.  Should I compile it straight
from source?  That's time consuming and often doesn't work.  Should I
install the package from an untrusted repository?  Should I settle for
an older version of the software, without the most current bells and
whistles?  And if I change my mind about the source code install, will
it uninstall gracefully?  This sort of stuff can drive you nuts.  It
becomes even more of a nuisance when you're installing developer
libraries and people haven't *quite* agreed where all the headers and
libs are supposed to go on a 64-bit Debian system.  That is to say,
the source build is often ignorant of installation issues on different
distros, and you have to figure it out yourself.

Packaging generally works for apps that have been tested and are
stable.  The minute you get into buggy apps that you need to debug,
packaging pretty much goes out the window and you're back to compiling
source code yourself.

Rather than authorize unreliable repositories, my best defense is to
download a package manually and install it by clicking on it.  This
works fine if the package is either self-contained or doesn't have too
many additional dependencies that I also must download and manually
install.  It's way simpler than trying to figure out how "pinning" is
*really* going to work in some corner case.


Cheers,
Brandon Van Every