Open Source's backwards-compatibility failure

Linux distributions with package managers like apt, promise an easy world of installing lots of great software. But they've fallen down in one respect here. There are thousands of packages for the major distributions (I run 3 of them, debian, Fedora Core and Gentoo) but most packages depend on several other packages.

The developers and packagers tend to run recent, even bleeding-edge versions of their systems. So when they package, the software claims it depends on very recent versions of other programs, even if it doesn't. This is not surprising -- testing on lots of old systems is drudgework nobody relishes doing.

So when you see a new software package you want, the ideal is you can just grab it with apt-get or yum. The reality is you can only do this if you're running a highly up-to-date system. Debian has become the worst offender. Debian's "Stable" distribution is several years old now. To run debian reasonably, even to just be able to upgrade to fix bugs in software you use, you have to run the testing distribution, and most probably the unstable one. I run the unstable, and it's more stable than the name implies, but ordinary users should not be expected to run an unstable distribution.

To get new software, you are often forced to upgrade, sometimes your whole OS. And that's free to do and often it works, but you can't depend on it. More than once I have lost a day of uptime to major upgrade efforts.

Let's contrast that with Windows. The vast majority of Windows programs will install, in their latest version, on 7 year old Windows 98, and almost all will install on 5 year old Windows 2000. This is partly because Windows has fewer milestones to test to, but also because coders know that it's quite a hurdle to insist users pay money to upgrade Windows. (And Windows upgrades are even more of a pain than linux ones.)

The linux approach ends up forcing the user to choose between the risky course of constant incremental upgrades, taking occasional random plunges into major upgrades, or simply not being able to run interesting new software or the latest versions and fixes of older software.

That's a failure. Non-guru users are not able to deal with any of those choices.

Testing with every different version of every dependent package (and every kernel) is not going to happen, but it would be nice if packagers worked hard to figure out what versions of dependencies they really need, even if they don't test it enough. Packages might say, "I was tested with 2.1, I probaby work with 1.0 though." Then wait for test reports and possibly report being tested with earlier and earlier dependencies.

This doesn't mean that sometimes you won't truly need the latest version of a dependency, and shouldn't say so. But it sure would make it easier for the ordinary user to particpate in linux if this was the exception, not the rule.

Two comments:

1. I run Debian testing on several machines (for several years now). I most often experience upgrade problems if I try to use apt-pinning and install packages from all three of stable, testing, and unstable. When I stick to just the testing repositories I experience the problem you describe very rarely. You can always force the installation to proceed when it thinks dependencies are unsatisfied (In dselect I think this is [shift-Q]) and if an earlier version of a "dependency" is really adequate then you'll be fine. I've always been able to ignore these for a few days and the Debian maintainers straighten it out. When it really matters to me, I file a bug, and then it's also straightened out. Good luck filing bugs on Win 98. Given how rarely this happens to me compared with how often I used to deal with Blue Screens of Death when I used 'doze I'll take this every time.

2. I've started using OS X recently to learn more about it. In only a day or two it occured to me how much I was going to miss Debian's incremental updates. While Apple's Software Update automatically pushes updates to you for their software, it is up to me to check for new versions of Firefox, Thunderbird, etc. for OS X. When a security flaw is uncovered, I may not know about it. This is bad. But with Debian I check for upgrades and security fixes for the entire system as often as I like and it's automatically handled for me. Maintaining OS X (or Windows) is, for this reason, much more work.

Brian

On the good-news side, I keep thinking that Debian "Sarge" (testing) is getting closer to a freeze. On the bad-news side, I've had that same delusion for several months now.

I'd also like to understand the other side of the dependency tree: if I were to accept the risk of upgrading some lower-level part of the system, which other packages of interest to me are freed up to a newer (not necessarily newest) version? Then, I could use the stability of various high-risk components to guide my upgrade decisions. For example, if there's a particular version of Gnome I'm interested in, I can check what higher-level apps have been tested against that particular Gnome independent of the specific global Sarge or Sid (unstable) release tracks.

It would require a more sophisticated capture of the dependencies: not only version numbers, but the particular triggers for the linkages. Is it a functional failure? (A major growth in functionality?) A minor bug fix? Do I need it, or just want it?

In effect, this would attempt to enable package-level software releases, with Debian adding tremendous value by tracking macroscopic stable release lineups (Sarge, Sid, etc). Other distros could presumably better advertise their own particular package version lineup to help folks decide the advantages and disadvantages of each distro.

[rant on] Having an interest in the industry, I'm much happier with a packaged system than a monolithic system: MS would be doing their shareholders a favor, IMHO, if they broke themselves into several separate companies (initially with common shareholders), and fully published "north-facing" APIs for each. Just because the DOJ demanded it for years doesn't mean it's a bad idea.[rant off]

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Post new comment

His name is Brad Templeton. You figure it out.
Please make up a name if you do not wish to give your real one.
The content of this field is kept private and will not be shown publicly.
Personal home pages only. Posts with biz home pages get deleted and search engines ignore all links
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.

More information about formatting options