[erlang-questions] Erlang package manager
Tue Dec 16 18:10:40 CET 2014
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