How about statically-linked builds? Hard drives and memory are cheap compared to the annoyances of having to manage dependencies on the user's system.

Package management is a solution to a problem that doesn't need to exist in the first place.

What do you propose instead? So far package management solves these problems for me:

  1. Upgrading the entire OS at once.
  2. Easy updates.
  3. Almost never having any issues with incompatible software. When issues arise I can easily roll things back or wait until they are fixed.
  4. Never having to hunt for software on the web.
  5. Ability to script server/workstation deploys.
  6. Never having to spend more than 5 minutes on maintaining my workstation.

That last point is huge. How long would it take you to update Java, Flash Player, Adobe Reader, IE and install SP# on Windows?

If there is an alternative way of approaching it I'd be very happy, since it can only be an improvement upon already stellar apt/yum/BSD ports, etc.

I'm only speaking to the dependency-resolution function that makes package management necessary on certain OSes. Public application repositories sharing a standard interface still have some nice features.

But if the applications are all statically-linked, I don't have to worry about dependency conflicts, and some things are a lot simpler, e.g. copying the binaries off to a flash drive to take them to another system, or running two different versions of the same software simultaneously.

On Windows, I don't usually even run installers anymotre; I extract the installers, collect all of the dlls into the application directory, and compress everything with UPX. Once the program is running out of a self-contained directory, I can run it off a thumbdrive, copy it to my Dropbox, etc. Plus I have the option of not updating software when I prefer not to.

I don't really see how your approach to installing Windows applications can scale. Also, pinning will allow you to hold back any packages you'd like.

The only potential problem I see is statically-linked applications issue. However, I think in the case where libraries are open and shared amongst many applications/other libraries, it makes no sense to use static linking. Its advantages are that you don't need to worry about dependencies but that "is a solution to a problem that doesn't need to exist in the first place" since package management takes care of these issues.

IMHO it's better to spend 30 minutes once a year resolving an issue that arose when a Debian/Ubuntu repository got screwed up for a short period of time, than to constantly try to solve the problem of managing software installation/upgrades.

Under Windows and OSX, statically-linked or self-contained packages are indeed the only way to stay sane when deploying an application.

However, this comes at a price: You'll always have to provide a newer version of the application whenever a serious issue is fixed in one of your dependency libraries. This means extra work for you. Also, you'll have to take care of an auto-upgrade mechanism.

On systems with a package manager, you'll only have to provide updates if you fix an issue in the application itself. You also don't have to write an auto-upgrade mechanism. Just upload a new package to your server.

However, if you don't care that much about users' security, statically linking is indeed a lot less work than using a package manager.

(FWIW, I'm the maintainer of Mingw-cross-env (http://mingw-cross-env.nongnu.org/). This is a project that provides a cross-build toolchain for statically linked Windows applications. It builds a cross compiler and lots of free software libraries. We have that kind of discussion from time to time on our mailing list.)

Then some central library has a security hole and half your system has to get updated, instead of just one thing.

Also, you might like http://sta.li/ ;)

Generally speaking, two vulnerable apps is less than twice as bad as one vulnerable app - and if a centralized repository means that all of your apps are fixed sooner they its a big win.

True enough, if the security hole is in a library that half of the software on my system is using. But most applications have fairly frequent update cycles for their own codebase anyway, and it's just as likely that an update to a central dynamically-linked library might introduce a new security hole that instantly compromises half of my system at once.

Thanks for the link to sta.li, I'll check it out. What I'd really like to see is a Linux distro that managed applications the way OSX does - every program is contained in its own directory.

IIRC, they still dynamically link against system libraries. It's just that OSX isn't a moving target with respect to what is expected to be in the system in it's 'base' state of a specific version. So you dynamically link against everything that should be in the system in the 'base' state, and then all other libraries need to be self-contained in the .app directory. The problem with this on Linux is that: 1) the 'base' configuration is a moving target that varies across vendors and 2) most of the libraries/etc that would make up that 'base state' are things that people would want to upgrade/modify/whatever (thereby messing up your 'base state' that you were supposed to be able to rely on) (You don't have this on OSX because Apple is the one that controls most of the things in the 'base state').

"What I'd really like to see is a Linux distro that managed applications the way OSX does - every program is contained in its own directory."

That exists, it's called Gobo Linux. I've never touched it, but you can give it a try:

http://www.gobolinux.org/

Hard drive space is cheap but bandwidth less so. Having only one copy of a library makes downloading, installing, and updating your OS much easier.