Neil Turner's Blog

Blogging about technology and randomness since 2002

Installing Pidgin on Ubuntu

I’m running Ubuntu Feisty Fawn, which I’ve previously installed Pidgin 2.0.2 on. Today, I wanted to upgrade it to 2.2.1, the latest version, using the package from Gutsy Gibbon, the next version of Ubuntu. This is a mistake.

Pidgin, it seems, depends on a lot of libraries. And, of course, these libraries have to up-to-date in order for the package to be installed. Eventually I got about halfway through the packages before giving up, because there’s so much stuff that has to be updated. The dependency tree goes several levels deep. For example:

Me: Please install Pidgin 2.2.1.
Ubuntu: Sorry, your version of gStreamer is out of date. Please update it first.
Me: Okay, install the new version of gStreamer.
Ubuntu:
Sorry, I can’t do that, because your version of libXML is out of date. Please update it first.
Me: Okay, install the new version of libXML.
Ubuntu: Sorry, I can’t do that, because your version of zlib is out of date. Please update it first.
Me: Okay, install, the new zlib.
Ubuntu: You do realise it’s better to use the old version of zlib you already have?
Me: No, I want the new version so I can run Pidgin.
Ubuntu: Okay, done.
Me: Now, install the new libXML.
Ubuntu: You do realise it’s better to use the old version of libXML you already have?
Me: No, I want the new version so I can run Pidgin.
Ubuntu: Okay, done.
Me: Now, install the new gStreamer.
Ubuntu: You do realise it’s better to use the old version of gStreamer you already have?
Me: No, I want the new version so I can run Pidgin.
Ubuntu: Okay, done.
Me: Now, since I’ve satisfied those dependencies, please let me install Pidgin.
Ubuntu: Sorry, your version of libGTK is out of date. Please update it first.
Me: loses the will to live

I realise now that installing a package that isn’t designed for the specific version of Ubuntu that I have is a bad idea, but seriously, why is it this complicated? Why can’t programs install their own versions of libraries, like on Windows (and presumably Mac OS X), and can’t these be distributed with the binary package?

Guess I’ll just have to wait for Gutsy Gibbon to be released properly.

6 Comments

  1. A package should never include libraries because that causes duplicates, and you want libraries to be provided by a single package so that you can get security updates easily.
    You can try backporting Pidgin to Feisty, but if it’s got lots of library requirements it probably won’t work.
    1) Add a deb-src line for Gutsy to your sources.list. 2) apt-get update 3) apt-get build-dep packagename;apt-get -b source packagename; 4) install the resulting debs.
    I don’t know how unstable Ubuntu pre-releases are, but it may be worth upgrading now if you really want the latest Pidgin.
    /me is now feeling rather smug that Pidgin 2.2.0 is in Debian Lenny and 2.2.1 is in Debian Sid.

  2. Actually, chances are that Pidgin generally doesn’t *require* the specific versions that were asked for, but since you’re installing a binary version, it does. Programs are linked to a specific version of libraries when they’re compiled into a binary, and generally require versions that don’t break compatibility. As I understand it, libraries can indicate whether they break compatibility or not by installing with a different version number in the filename – hence things like libblahblah.so.0, libblahblah.so.1, etc. (This is what’s referred to as “binary compatibility”.)
    The .deb files used by Debian, Ubuntu, et al. are generally made to point to the same versions of libraries that accompany the release that they’re distributed in. Thus, your Gutsy Gibbon .deb of Pidgin is probably going to require Gutsy Gibbon versions of the libraries it depends on. This is because it’s known to work with these libraries. Pidgin itself – even the binary version – may work using the old libraries you have, but it’s not guaranteed and weird things could happen.
    There’s an easy way to get around this, and that’s by installing from source. It’s not hard to do, and I believe Debian and Ubuntu have facilities for doing it automatically. Building fom source will cause the binary version you compile to link against the libraries that *you* have, and should thus work. If you come across problems in the configure stage with other versions of libraries needed, that’s when you know it really does need newer ones.
    As for why programs can’t come with their own libraries – that’s because different distros might patch their libraries in different ways for various security issues, or filesystem differences, etc. That’s not to say that a vanilla built-from-source version wouldn’t *work* on each distro – it most likely would. However, any benefits gained from the distro patching would be lost and inconsistencies could appear in the operation of things. Windows doesn’t have this problem because you don’t get “distributions” of Windows; they all come from the same vendor, so there’s no worries about this stuff.
    There *are* programs on Linux which actually do distribute their own binary versions of libraries, but generally only those which distribute binary versions of the program themselves, not just source code (which is then distributed as binaries by other people). Second Life is one of them; when you download the binary version of SL for Linux, it comes with its own binary libraries and uses them if need be. However, that’s the exception rather than the rule.
    There are ways to get around this, such as by using a source-based distro such as Gentoo. (Don’t laugh, it’s actually easier to get set up than you might think, especially now that it has a graphical installer and LiveCD just like the best of ’em.) Since on Gentoo pretty much everything after the initial install is compiled from source, there’s no worries about the binary compatibility issue, only the issue of whether these new versions really *are* needed or not. And Gentoo makes it really easy to install packages; you don’t have to execute any compilation steps yourself. (Some people will tell you that the main attraction for Gentoo is the speed and customisation for your particular CPU and such; ignore them, they don’t really get it. IMO, the *really* good feature of Gentoo is the USE flags, but that’s a topic for another post.)
    Anyway, hopefully this helps to explain it a bit. Sorry I rambled on for so long!

  3. 1) always use a testing responsibility (in this case Gutsy Gibbon)
    2) use mixed source. this need package pinning, see http://www.debian.org/doc/manuals/apt-howto/ch-apt-get.en.html section 3.8 to 3.10 for more details

  4. I’m currently running a dev-build of Gutsy and it’s pretty darned cool. You should consider running a dist-upgrade ๐Ÿ˜›

  5. I have always found the dependancy issue fairly simple using *buntu. What does worry me is, as a previous poster suggested, duplicate dependancies. The problem is it is quite hard, for me, to check for this. Perhaps I lack experience (I do) but it does make me worry when the built in package manager goes awry.

  6. “Why can’t programs install their own versions of libraries, like on Windows (and presumably Mac OS X), and can’t these be distributed with the binary package?”
    Neither Windows nor Mac OS X do this consistently; sometimes, programs install their own versions in a shared place, sometimes they install it just for themselves, sometimes they rely on other packages.
    The problem with packages installing their own versions is space (Ubuntu comes with a lot more software), runtime inefficiency, and, most importantly, inconsistencies and incompatibilities.