A visible case against bundled libraries

I wrote a lot about bundled libraries and why they are bad, but I usually stick with speaking about Free Software (or Open Source Software — yeah they are two different sets!). This time, let me explain you how they are bad for proprietary, binary-provided software as well.

For a long-winded story, I finally decided to give a try to Dropbox after hearing so much good about it. Thanks to Fabiano who wrote it, I got a rough ebuild for the nautilus-dropbox extension, so I cleaned it up a bit and installed.

The first step of the set-up process is… downloading the “proprietary daemon”, which turns out to include a number of otherwise Free Software, including, but not limited to, a number of Python extensions (and of course, a _whole copy of the Python interpreter_… they don’t even as far as trying to hide it, as all the symbols are visible in the ELF file!), Zlib 1.2.3 and a couple of D-Bus related libraries.

Okay nasty, but let’s leave at that for now, proprietary software can easily be crap, and I say that as somebody who also works on proprietary software for jobs from time to time, and I don’t expect them to have too much intention to clean up their code for what Free Software developers would call quality. But on the other hand, I expect they’d be trying to make it possible to run their code on the widest range possible of systems.

So I ignored for now the fact that it installs a proprietary package without being allowed to package it properly in the distribution, and I went on to configure it. Only three other steps are involved in the setup process: logging in with your email address and password, choosing your subscription type (I went for “Free”… while I am/was considering getting a higher version, it’s try first and decide later!), and deciding where to put your Dropbox folder.

Call me old-styled but I like my GUI-important folders on the desktop, so I wanted to put it there alongside “Downloads” and “Documents”.

Whoops! Window disappear as soon as I click the button to choose the placement. Smells funny, let me open the console and see:

/home/flame/.dropbox-dist/dropbox: symbol lookup error: /usr/lib/libtracker-client-0.7.so.0: undefined symbol: dbus_g_proxy_set_default_timeout

A quick check tells me two things: the symbol is part of libdbus-glib.so.2, which libtracker-client-0.7.so.0 links to properly, and Dropbox has a local copy of that library, which overrides my system copy. Unfortunately, their copy is older, so it lacks that symbol. Hilarity ensures.

Speaking about which, please do remember that most libraries don’t change SONAME when they make backward-compatible ABI changes, but the same is not true for forward-compatibility! So you can use software linked against an older library with a new one, but not vice-versa. It’s a nasty thing to forget.

I decide to simply hack this around and remove their copy of the library and try again… this time it works, but I lack all possible icons. The reason? I’m using an SVG-based icon set; the SVG renderer uses libxml2; libxml2 uses Zlib… they ship with Zlib 1.2.3 but my libxml2 is looking for the versioning from 1.2.4. Thanks to the fact that it’s just a plugin, this time it doesn’t kill the process (yes this is one of the few good reasons to use plugins), and I just lose ability to see icons.

I’ve opened a ticket for this with Dropbox, but I don’t really want to get my hopes up. What I’d love to see them do (still keeping a pragmatic mind — I won’t expect them to opensource all their implementation since they have been keeping that explicitly proprietary up to now):

• make it possible to package the daemon from the distribution level, so that it’s not downloaded and installed per-user;
• allow for a quick way to remove the bundled libraries, bringing in on the system the needed dependencies;
• possibly make available a version of the daemon that does not link in the whole Python interpreter so that distributions can use their own system interpreter.

So if somebody from Dropbox is listening: please work with us distributors. You only have to gain from that. Better experience with your service on our users’ desktops is likely going to bring you more money, as more people are likely to buy a subscription. For what it’s worth, I would buy one myself, if it worked as a charm and not in the current hackish way on my systems.