Hacker News Reader

Comment by olgeni | Hacker News Reader

Yes - in the beginning.

If you look here https://github.com/erlang/otp/releases you'll see that - even on Jessie - 17.1 is unfortunately way behind.

View on HN

Jessie is using 17.3.4 (if I am reading the version correctly), see https://packages.debian.org/jessie/erlang

17.3.4 was released on 4th of November 2014, according to the link you provided.

Jessie "freeze" happened on 5th of November ( https://lists.debian.org/debian-devel-announce/2014/11/msg00... ), so I even wonder that they are shipping that version.

In my opinion that is not "way behind".

If you need bleeding edge you should move to unstable or testing releases, move to a rolling release distribution like Arch or build your own.

I tried to work this out as well. It is indeed using 17.3.x but its hard to nail down which point release, as the Debian changelog doesn't mention when they pull a new upstream version (vs fixing an issue in the package itself)

I figured I would just install the package and use a -v or --version arg to get the exact build version. I cannot find any way to get a patch version out of Erlang. The `OTP_VERSION` file simply says 17.3, and the most I can get from `erl` or `erlc` is "17".

OTP_VERSION lists minor releases, so that should be a "true" 17.3.

I think this is a massive downside for Linux, and saying "use unstable" just puts the onus on the user to solve it for themselves. Stuff like PHP, MySQL/MariaDB, Postgres and Python isn't part of the OS anywhere else, but it is on Linux. Making tons of third-party userspace software part of the OS distribution causes the distribution of that software to lag behind on Linux. I don't see any reason that what version of Debian you use should lock you into a default version of Erlang, instead of simply letting a user install whatever version of Erlang they need quickly and easily. For all the bleating during the systemd flame war about how Debian and Linux is about choice, it's a very constrained form of choice.

EDIT: Well, that's not true, I see the reason -- Linux isn't an OS so much as it is a family of OSes that are assembled from a lot of independently developed projects and are loosely compatible with each other, so the reason you need a Debian-specific version of Erlang is because Debian isn't quite the same as Arch or Fedora or what have you. I just don't think that it's such a great reason that users should just accept that it'll never get better.

I think you are looking at it wrong. It is not just "use unstable", it is "use unstable if you want to apt-get install stuff".

You can always install the version you want, you just have to compile it, including it's dependencies if needed (using a custom path for libraries).

If you need to do that for multiple machines, build your own packages.

You have a choice how you want to get stuff on your system.

People creating software packages that are in the official repository make it easy for multiple projects to reuse stuff and it works out for most people most of the time.

Looks like 17.3 from the package name. Today it might not be "way" behind, but it will be in a year or two. Or three.

I can see the point of having a "stable" kernel, but these freezes are mostly random. Back in its days, Squeeze shipped with R14A (not B). That's not stable, it's just a random cutoff. It means that whoever did the package did not even know what A and B used to mean in Erlang releases.

That's not something you can put in production.

This is what backports is all about. More up to date packages from sid, built for the current stable release.

If you're a heavy erlang user you could also consider helping to support the Debian packages for it, I'm sure they'd (Debian erlang team) appreciate any help offered.

Generally I start off with stable, add things via backports if possible, then build my own solution for the primary language runtime and any libraries I'm using.

The idea is to lean on stable for everything else that you don't care as much about, basically.

Reply on news.ycombinator.com