[erlang-questions] Erlang package manager

Eric Pailleau eric.pailleau@REDACTED
Tue Dec 16 18:10:40 CET 2014

your opinion.

There is already esl-erlang packages for Erlang core and libs.
I write on package for erlang applications.

Doing OS packages for an Erlang application may need other tools , and dependencies to esl could install the right Erlang vm version.
the main problem to address is to be able to install and use several VM version in parallel , like alternatives with java. kerl ?
I do not talk on embedded system  releases.

And not mentioning native code.

« Envoyé depuis mon mobile » Eric

zxq9 <zxq9@REDACTED> a écrit :

>On 2014年12月16日 火曜日 15:56:22 Eric Pailleau wrote:
>> I forgot to say that Erlang packages may need Non Erlang application, like
>> Postgresql, or Varnish or (fill blanks). Debian Meta package allow this,
>> for instance. This could not be achieved with a specific Erlang packager.
>There are no Erlang packages or builds that require Postgres. Some C 
>interfaces may require Postgres headers to build (and these are not "Erlang 
>packages" in the strict sense), but most Erlang systems that have anything at 
>all to do with something like Postgres need to be given the address of a 
>servicing port with which to connect.
>This is not an Erlang build issue. At all. Ever.
>The way this is handled is through OS distributions -- and if the decision 
>were made to include this sort of "build" support (or rather, not "dep 
>resolution" but "adjacent service provision") then the package manager would 
>wind up becoming its own OS distro in short order, and from there wind up 
>trying to be OpenStack. And it can't ever be that. Not even anything remotely 
>close to that.
>The only thing even sort of close would be for Erlang to pick a single distro 
>of a single OS on a single platform and settle on that as the sole reference 
>implementation forever and ever, amen, and pour time into maintaining that 
>(blessed) distro's Erlang subsection of packages through its package manager. 
>This, actually, is workable from a technical point of view -- but is 
>guaranteed to not be socially workable, even if it were done in the Belly of 
>Some Beast (neither MS nor IBM has been able to pull this off, and they own 
>their entire stack) -- actually, I imagine the annoyance of keeping up with 
>this sort of thing is why Erlang was spun out of Ericsson in the first place.
>And that leaves us back at the original problem, which has been demonstrated 
>to be twofold:
>1- Define an ecosystem within which code can be grown and known to survive with 
>a minimum of wasted developer effort.
>2- Set clear limits of that ecosystem.
>The ecosystem definition is really more important than any particular 
>implementation of a tool within it -- but that gets into standards, and who 
>follows those without a reference implementation anyway? (And who spends time 
>writing *and* maintaining new implementations when the reference platform 
>already works well? We want to do more interesting things with Erlang than 
>write more Erlang, I imagine...) It has to be complete enough to cover the 
>problem space so that something can be implemented in the first place -- but 
>absolutely can't go so far that it suffers from second-system-syndrome.
>I've got plenty of ideas what the above statements should mean, but that's not 
>the point of this message. My purpose is to point out straight away that this 
>entire idea will be DOA if we let the Good Idea Fairy serve up a big dream 
>steak smothered in hope peppers with a side of good intentions and a community 
>love salad before even a line of code has been written.
>erlang-questions mailing list

More information about the erlang-questions mailing list