Hacker News Reader

They don't just solve dependencies they encourage dependencies

This is a good thing. Developers' attitude toward dependencies gets very lax when it's too much work to declare them or too much work for the user to satisfy them. Then you get into situations where you install a piece of software and 90% of the functionality is broken, because the developer was "considerate" enough not to "force" a bunch of dependencies on you, so you resort to Google to find the real dependencies, which of course aren't available for your distro. Apt gives developers a flexible way to declare different kinds of dependencies, and the Debian and Ubuntu distro repositories give them confidence that the dependencies will install smoothly for users.

I had much more difficulty with undeclared dependencies back in the day than I have with excessive dependencies now. It's just wrong for software to easily install in a mostly broken state. If you want broken, partly-working software, you should have to do extra work to achieve that, not the other way around.

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.

Ubuntu's strategy to not let you upgrade some packages without upgrading the OS itself is insane.

You can; it's called "pinning:" https://help.ubuntu.com/community/PinningHowto

If I want Python 2 and 3 on the same system I can't have a package manager tell me that's not supposed to be when I know full well that it's no problem.

Let me check; here on Jaunty I can separately install python2.4, python2.5, python2.6, python3.0, & python3.1.

I don't doubt that you've had problems with the package managers, but, um, I think you're doing it wrong.

I guess what I'm "doing wrong" is to expect sensible out of the box behaviour. I'm fully aware that I can make it do whatever I want to if I put enough work into it. That holds for almost everything in life. What's limited in my life, though, is time.

Installing Python 3 alongside the old version didn't work for a long time after Python 3 came out. If it works now, that's fine. I compiled my own Python 3 a long time before it finally appeared in my system's package manager.

[Edit] And one more thing. I'm not a sysadmin and my interest in system configuration and change management is very limited. But I've been using Linux for a very long time, so if I'm still doing it wrong then many people will do be doing it wrong and that means there's something wrong with the way it works.

On the contrary, you're acting like you desperately want to be a sysadmin by demanding to control which specific version of each package is installed.

No, I want developers to be in control of dependency management.

> The package manager concept is actually what I hate most about Linux systems

You really should give Slackware a try. None of that sophisticated package management nuisance[1] and everything just works!

[1] http://en.wikipedia.org/wiki/Slackware#Package_management

I'm not sure I would say "everything just works" and Slackware in the same sentencd!

I'd say "Everything just works as expected"

> Ubuntu's strategy to not let you upgrade some packages without upgrading the OS itself is insane.

you're doing it wrong