The (old) Licquia Family Blog

This is the old blog site, powered by a simple blogging system called Blosxom. It's here to keep old links from breaking, and for whatever historic interest might remain.

Here's the current site.



Sat, 10 May 2003

Journaleering, part 2

A slightly older post takes Nick Petreley to task for promising a simple solution to a hard problem: software package compatibility. Summary: I was doubtful.

The final part of that series has been up for a while now, with his solutions to the problem. Not surprisingly, his solutions are a mix of obviously good ideas and some wishful thinking. Rather than go through the whole article, I'll hit on some of the high points

Use static linking whenever possible. This is an obvious answer to the problem of resolving dynamic library problems. However, security problems or other bugs in the library can't be fixed unless you rebuild. Worse, since the dependency information disappears, you often don't even know you have a security problem in some software that statically links a library. Look at the archives of Debian security announcements for the "zlib" bug for an example; there are a few cases where apps that statically linked to zlib or incorporated its source code had to be updated separately.

It's also possible in some cases for clients to remain compatible with servers they use even after major changes. If the client library is dynamic, it can be updated to talk to the newer servers without disrupting the old apps. This obviously doesn't work with static apps. Indeed, the packaging system will often report that your system is perfectly fine after an update (remember, again, that the dependency information disappears), yet your apps will mysteriously break. That's an improvement?

Design the application to look for resources in separate, identifiable directory trees. This isn't a new idea; see the stow project for one fine example of a system to manage just such a configuration. The HURD was, at one time, supposed to use overlapping mounts on /usr/bin and /usr/lib to solve the problem in a slightly different way.

Create and adopt a new dynamic-link wrapper. This is where a lot of the wishful thinking kicks in. We might be able to write an extension to the dynamic linker that looks in "foo/lib" for a dynamic library needed by a program in "foo/bin", but that's about it. The "framework" idea is a little unclear; the simple form (adding framework paths to the linker) is already supported, while the more complex one (figure out that a particular app is a KDE app and look in the KDE framework path) is unreasonable. How is the linker supposed to know that an app is a KDE app, after all?

Firewall-incompatible versions or build-in backward compatibility. That's like saying "to have world peace, all we need to do is stop declaring wars". Fine, but how do you do that?

Backward compatibility is possible now with the existing dynamic linkers; look at the changes glibc has gone through, and how well old apps use new versions of that library. Yet we still have problems, mostly because library developers can't be forced to follow the rules.

Resolve dependencies by file, not by package. And how, exactly, do you figure out which package contains "/usr/lib/libfoo.so.2" without package dependencies? Right: you store file-to-package associations. Which makes file deps devolve to package deps, with an added indirection layer to confuse the poor user who just wants some app installed and doesn't know where "libgnomeprint.so.15" is supposed to come from.

He hints at another problem, but basically handwaves it away: unresolved symbols from newer versions of the shared library. His "solution" amounts to "look really, really hard for it". One solution might be to declare a versioned dependency on the package containing the library, but Nick says that's bad, remember? I think that Debian's solution is probably as good as we can get: store the proper dep in the development library package, and have a program automatically calculate the dependencies by looking at what libraries the app uses and pulling the embedded package deps in.

I am particularly incensed by the implication that "that problem is political and beyond the scope of this discussion." Thanks, Nick. You just accused me (and others) of holding the solution in the palm of our collective hands, but refusing to use it because we really love to screw our users over for the gain of our own egos. But never fear: the journalists are here to save the world from the evil engineers!

(Side note: RPM has both of these features right now: file deps and versioned symbol deps. It even has deps on RPM features you need, which RPM magically translates into a versioned dependency on the "rpm" package. None of this helps; in fact, it hurts in some ways.)

The junk drawer. My words, not his, for points 3 and 4 on the second page. Anything with missing deps gets thrown in a junk area instead of being installed onto the system, without removing the stuff it's supposed to replace. I haven't a clue what this solves. Both Debian and Red Hat package managers refuse to install a package with missing deps already; what difference does it make that the package gets thrown in a refuse pile, given that it won't work anyway?

Generate something based on the end results. Running apps from a script instead of directly is sometimes a good idea. Reconfiguring the dynamic linker with each package install doesn't sound like a good idea. I might be convinced if I had any idea what this was supposed to solve.

Well, enough slamming of Petreley. If there's interest (like, say, any comments or TrackBacks to this post), I might post my own ideas about making the process easier. At a fundamental level, though, you can't get around the fact that packaging is hard work. You can't wave a magic wand and make any software, generated anywhere, work on any computer. Part of the process of making a distribution involves making sure everything plays well together and fixing the problems you run into. Source-only distros like the BSDs and Gentoo solve some of the problems, but they don't make the problem go away completely, and they introduce other problems which some people might find more troublesome.

May 10, 2003 | Comments are no longer available