I've been a user of
Debian's apt-get package
manager for nearly as long as I've been serious about computers,
and I love it. Going back to a system that lacked apt's depth and
stability would be like having to write with my non-dominant hand
or worse—going back to typing on a QWERTY layout. I have
seamless access to everything I need[1], and it
never breaks unless I do something crazy like add unsupported
third-party repositories or run the unstable distribution. Who
could ask for more? So I'm quite proud to see
Leiningengetting
packaged for Debian with lots of help from the Java
Maintainers team.

It's interesting to get a look inside the sausage factory of
packaging. The biggest hurdle for me as I was learning the ropes
was that all the packaging introductions assume you are building a
C program and
have familiarity
with makefiles. You can tell that the packaging culture has
its roots in C, and packages from other runtimes feel a bit
foreign.[2] Even more so with a language like
Clojure... you're off into unexplored territory, blazing your own
trail.

The biggest change from what I'm used to is the notion that only
a single version of a package can be installed at a time. I think
I understand the motivation here: it's crucial that when a
security vulnerability is reported the affected packages and all
those that depend on them have access to the fix. I'm used to
developer-focused package managers that allow many versions to be
installed side-by-side, but that places the burden of security
updates on the developers using it since it's common for packages
to depend on exact versions rather than allowing bugfix versions
to sneak in. It's a lot more work to track down security issues, but
this is not a big deal in the context of developer-centric systems
since these particular users are less likely to mind having to pay
attention to that sort of detail; it's what they're paid to
do.

So there's a real tension here; end users want packages to just
work and be safe without thinking about them while developers
demand repeatability and control. Developers need the flexibility
to choose exactly when they want to pull in new versions of
libraries, while end users want things to hum along out of
sight.

The problem is that the one-version-of-a-package-at-a-time policy
doesn't always work in practice. Over time backwards compatibility
is the exception rather than the rule; in many cases there simply
is no substitute for having multiple versions of a package
installed simultaneously. And apt's answer here is just to create
a new package with the incompatible version number as part of the
package name. There's no clue that these packages are related, and
upgrades won't pick the new versions up. This is quite a shame,
because I love everything else about apt. I look at complicated
production deployment schemes and think to myself how much simpler
things would be if deploying were just a matter of adding our
internal apt repository and running apt-get install,
but... versions.

Of course, these gripes are not really relevant to having
Leiningen in Debian.[3] Users of Debian-based
systems will be well-served by getting Leiningen through their OS,
and once it's on their system, they're free to use it to solve
their developer-centric problems. This plays to the strengths of
each system, and everybody wins.

[2] It's especially noticeable with Ruby and
the JVM. Part of this is due to the fact that the JVM has only
been free software for a relatively short period of time, and a
lot of the existing culture around Java distribution goes against
the grain of repeatable builds by ignoring source and shuttling
binary bytecode around everywhere.