On Linux, you can choose just how much you want to maintain yourself vs let the system maintain, which means you can minimize this type of pain.

Note that I have supported various commercial packages on Debian systems without a problem either. Debian doesn’t remove old sos on upgrade unless requested, so things don’t break, even across major upgrades, even when they have very odd binary dependencies. I have libc5 gcc 2.8-specific C++ x86 binaries that still work, no effort required.

Contraily, with a system like FreeBSD or Solaris, the pain is typically entirely upon the local administrator to deal with the most recent apache problem.

I can’t tell you how many times as a commercial software vendor I’ve had to drop everything to deal with some major incompatability introduced by a minor update from a proprietary unix vendor, even though they insist that they’re always ABI compatible. Typically these are situations where you can claim the external symbol signatures haven’t changed, even when the behavior, location, environment variables, or other aspects have.

As a proprietary software vendor it is easier to support Linux systems than any other unix. That includes all the flavors. Really.

If everything you run comes from a package that’s tested by the vendor, and you’re upgrading from one compatible package ecosystem to another, and your config file formats don’t change, your upgrade should work just fine (though results may vary in the wonderfully fragile world of Red Hat). That, however, has absolutely nothing to do with the argument, because that’s simply not the way that the world of proprietary software on commercial UNIX distributions works. The vendors don’t run in lock-step with your operating system, and they don’t provide special repositories so that the Etch version of their software is replaced with the Lenny version when you upgrade. (In fact, you’re remarkably lucky if they even support anything besides Red Hat or SUSE at all.)

As a Debian guy, you’re probably more used to the FOSS side of the spectrum, so let me just use a generic example from that arena. Say that for whatever reason, you’ve compiled a local version of PHP against OpenLDAP 2.3, and your distribution decides it wants to start using OpenLDAP 2.4′s ABI/soname-incompatible client libraries instead. You upgrade, and suddenly you’ve introduced a problem for yourself if you haven’t made a habit of specifically linking against a ton of your own manually-tracked dependencies, because your libldap2-3.so.0 happens to not exist anymore. You now need to hunt down and re-link all of your dependencies, some of which may not be apparent until certain edge cases during run-time are encountered and a handful of DSO’s are loaded on demand and your programs begin mysteriously crashing because they’re trying to call externs that don’t actually exist.

Thankfully, we haven’t had ABI changes the size of libc5->libc6 in many years, but it’s absolutely conceivable that an upgrade can break a great many things if you rely on the fact that system libraries are going to stay one particular ABI version between releases.

I’ve had Linux systems seemlessly upgraded across versions of Debian for over 7 years without service interruption. This includes production systems providing live services. People do not reformat instead of upgrade.

I didn’t mean for this to turn into too much of a discussion about Sun’s packaging system in general; it’s been covered before in much greater depth by people with much greater knowledge than I on all things Solaris. It was mostly intended to explain to Linux-centric people why Solaris’s third-party package ecosystem is so bare-bones compared to Linux’s, and why a lot of effort goes into building a full stack from source. Since nobody else is commenting, though, there’s no reason to be afraid of a little derail.

SysV packaging is definitely showing its age, and you’ll find few outside of the hardcore Sun faithful who actually try to defend it. IPS in OpenSolaris is still dog slow, much slower than any modern package manager ought to be, but I think it does address most of your concerns. Sun has a decent introduction to IPS packaging in their OpenSolaris docs. Also see the command reference for pkg(1), which has some other useful information in it.

Here’s the nickel version:

IPS handles upgrading pretty seamlessly. Not only does it handle upgrades in the sane way expected of a modern package manager, but it also can take a full ZFS snapshot of your boot environment so you can roll back to a known-working package set without a lot of fuss. (This isn’t hard using RHN Satellite or Spacewalk either, from the Red Hat side, but it takes a lot more plumbing and infrastructure and relies on your ability to downgrade packages cleanly.)

Checksums are handled well by “pkg verify”, as are other things that any other modern package manager could sanity-check, like permissions. OpenSolaris loses points by not having the output format easily parseable/scriptable like the output of “rpm –verify” but the functionality is in place and usable, at least.

Querying and listing packages is done through “pkg contents” and “pkg search”. These functions work identically on local and remote packages, which gives IPS a tiny leg up on its Linux counterparts.

It also manages dependencies pretty well — that was more or less the entire point of bringing Ian Murdock on board with Sun’s platform team. The lack of a regular Internet-oriented package manager like most Linux distros have had for a very long time is definitely something that’s scared a lot of Linux users away from Solaris.

Of course, this means pretty much nothing to you if you’re not running OpenSolaris, which takes some balls to do at this point. And, like any major change in an OS like Solaris, it introduces its own set of problems. Here’s a quote from the pkg(5) manpage about package version numbers:

The first part is the component version. For components tightly bound to OpenSolaris, this will usually be the value of ‘uname -r’ for that version of OpenSolaris. For a component with its own development lifecycle, this sequence will be the dotted release number, such as ’2.4.10′.

How very intuitive, Sun.