[JoshTriplett]

"I know you have all these rules that try to make packages consistent so sysadmins don't have to give any extra thought to each individual one, but I'm a special snowflake that you should treat differently."

I care about having a system with hundreds or thousands of packages installed on it that all work consistently.

Linux is not OS X, and packages are not .dmg files; I want your package using the system version of libfoo, not your own fork of libfoo. If you have awesome changes to libfoo, then you should either get them into upstream libfoo, or go all the way and actually fork libfoo into libfooier upstream to allow packaging it separately.

[dvanduzer]

Reading your comment, I am starting to understand why everyone is so confused about this.

Linux and OS X both have the same underlying options for static or shared libraries. There is a large amount of "enterprise" software that is distributed just like a .dmg file.

There is plenty of middle ground between having everything dynamically linked and everything statically linked. The author of the article believes that packagers should trust developers to make good decisions. (Granted, there are plenty of bad developers and abandonware galore. Packagers are justified in stepping in to make new decisions here.)

[mwcampbell]

As a sysadmin, which do you prefer: self-contained software distributions with all the dependencies included, or packages that use the host distro's package manager, use system versions of libraries wherever possible, and otherwise integrate well with the host system? The latter seems better to me, but it's an honest question, not rhetorical.

[grosskur]

False dichotomy---bundling dependencies doesn't preclude integrating well with the host system. See Basho's latest Riak package for Ubuntu 12.04:

http://s3.amazonaws.com/downloads.basho.com/riak/1.3/1.3.2/u...

It integrates well with the host system (init script, "riak" user/group, data in /var/lib/riak, logs in /var/log/riak, etc.) and bundles dependencies in /usr/lib/riak.

In my experience, bundling dependencies is often the only practical way to install a complex app. Take Sentry as another example:

https://github.com/getsentry/sentry

The current version (5.4.5) depends on 37 Python packages:

  BeautifulSoup==3.2.1
  Django==1.4.5
  Pygments==1.6
  South==0.7.6
  amqp==1.0.11
  anyjson==0.3.3
  billiard==2.7.3.28
  celery==3.0.19
  cssutils==0.9.10
  distribute==0.6.31
  django-celery==3.0.17
  django-crispy-forms==1.2.8
  django-indexer==0.3.0
  django-paging==0.2.5
  django-picklefield==0.3.0
  django-social-auth==0.7.23
  django-social-auth-trello==1.0.3
  django-static-compiler==0.3.3
  django-templatetag-sugar==0.1
  gunicorn==0.17.4
  httpagentparser==1.2.2
  httplib2==0.8
  kombu==2.5.10
  logan==0.5.6
  nydus==0.10.6
  oauth2==1.5.211
  pynliner==0.4.0
  python-dateutil==1.5
  python-openid==2.2.5
  pytz==2013b
  raven==3.3.11
  redis==2.7.6
  sentry==5.4.5
  setproctitle==1.1.7
  simplejson==3.1.3
  six==1.3.0
  wsgiref==0.1.2

Ruby or Node apps have dependency trees of similar or greater size. It takes an enormous amount of effort to roll all of these as individual packages (yes, I've done it) and it's a colossal waste of time once you realize you can have a working package in under a minute with virtualenv, pip, and fpm:

  $ virtualenv --distribute /opt/sentry
  $ /opt/sentry/bin/pip install sentry
  $ fpm -n sentry -v 5.4.5 -s dir -t deb /opt/sentry

[nbouscal]

For my boxes I'm at the point of striking a middle ground. I use system versions of libraries wherever possible, but in many cases I compile the actual applications from source. The package manager tends to be too many versions behind, and a lot of the software I use is in active enough development that the difference is actually of significant importance. If the package managers updated more quickly, I'd use them.

Edit: Also, the package managers have an awful habit of installing dependencies that are not actually dependencies. Drives me up a wall.

[dvanduzer]

Every organization's needs are different. A large operation like Heroku has a large server footprint, but a very uniform build. A large operation like General Electric might have a large server footprint, but with all sorts of bizarre business requirements that you or I couldn't even imagine.

(I spent the first half of my career in the ISP business.) If I see something as an infrastructure cost that scales slowly but surely, I want a standard distro package wherever I can get one. Sometimes you're in an environment where you've got extremely specific vendor-or-client-imposed requirements, and the best you can hope to do is standardize your configuration / deployment process.

I've had environments where I cared more about CPAN or PyPI than yum or apt (or RHN or roll your own). If I have N00 servers doing the same thing or N00 servers doing a variety of things, the answer shifts.

[kiallmacinnes]

This.

Very few people understand the importance, and benefits, when they have never seen anything other than .msi[1], .dmg, or worse, .zip.

[1]: Lets just pretend for a minute that Windows software only comes as plain MSI.. all the various .exe's which splatter stuff all over the disk simply doesn't exist.