[erlang-questions] Building, Packaging and Installing

[Tim Watson]

This came up on the erlware lists as well. Although both Eric and I
were hoping to put something a bit more structured in place before
discussing it with the community, the gathering pace behind this
thread suggests to me that there's little time for writing things up
so here are the links to those discussions:

- original idea from Eric:
https://groups.google.com/forum/?fromgroups#!topic/erlware-questions/GtFBTQtgeng
- overview: https://groups.google.com/forum/?fromgroups#!topic/erlware-questions/omunsj8pfs4
- some of Joe's questions we already visited:
https://groups.google.com/forum/?fromgroups#!topic/erlware-questions/ZbRdDAkFQPo
- repository design questions:
https://groups.google.com/forum/?fromgroups#!topic/erlware-questions/vNHjrvIScGE
- erlang/repository namespace issues:
https://groups.google.com/forum/?fromgroups#!topic/erlware-questions/cav3oK_D8sw
- code signing:
https://groups.google.com/forum/?fromgroups#!topic/erlware-questions/1esqRJU11EE

I hope they provide some useful inputs to this idea for everyone's
benefit. Note that as far as I'm aware, no implementation work has
gone into this yet, although I have done some prototyping with git as
the fetch/synch mechanism using rather low level commands such as
fetch-receive-pack, which I mentioned towards the end of this thread:
https://groups.google.com/forum/?fromgroups#!topic/erlware-questions/js06abXa8Mk.

Cheers,
Tim

On 7 May 2012 14:31, Tristan Sloughter <tristan.sloughter@REDACTED> wrote:
>> > 7) Binary or source packages?
>> >
>> >    - Ummm - tricky
>> >
>>
>> I think binary is better but adds a lot of complexity. Erts versions,
>> projects containing native code, etc. makin this the publishers
>> responsibility means the tool only has to focus on the packaging problem not
>> the build space. Third party  signing allows you to support sources which
>> gaven't been published by the originator.
>
>
> I'd be happy with starting with just a source solution, but I think a binary
> one is definitely needed and can be simplified with TravisCI -- it'll build
> with multiple Erlang versions.
>
> I really wish I could plugin to the hosted TravisCI to have a job run to
> publish artifacts. I only briefly looked into that, so maybe something there
> is possible.
>
> Tristan