<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 9, 2015 at 11:08 AM, Roger Lipscombe <span dir="ltr"><<a href="mailto:roger@differentpla.net" target="_blank">roger@differentpla.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":ob" class="a3s" style="overflow:hidden">3. Failing that, how are other people deploying Erlang? Do you just<br>
unpack a tarball into /?</div></blockquote></div><br></div><div class="gmail_extra">Releases.<br><br></div><div class="gmail_extra">A release packs an ERTS together with your code, so it is self-contained. You then don't have to deploy an Erlang package next to your code. Whatever ERTS the build-host uses is the one that is packaged into the release. This solves the problem of having a locally patched Erlang.<br><br></div><div class="gmail_extra">For building Erlang releases, anything now goes. We use kerl, but we don't require special patches on top of Erlang, just some compiler flags (--disable-hipe, --enable-dirty-schedulers,--with-dynamic-trace=dtrace). However, this is easily adaptable to a patched world with the (experimental) kerl git option.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">We often simply deploy these as tarballs which we unpack somewhere (/opt/foo or /usr/local/foo depending on OS type). Then we install some start-script for them and we are good to go.<br><br></div><div class="gmail_extra">I spent much time trying to get packaging right in $OS, but recently, I've had more success with the above low-level method. In a world where it is easy to "roll a new machine", you can just use that machine as a starting point. You don't have to worry too much about being able to remove software from the system again, which is one of the primary reasons for the existence of package managers.<br></div><div class="gmail_extra"><br clear="all"><br>-- <br><div class="gmail_signature">J.</div>
</div></div>