[erlang-questions] Coon - new tool for building Erlang packages, dependency management and deploying Erlang services

[Vlad Dumitrescu]

On Tue, Feb 13, 2018 at 10:55 AM, Jesper Louis Andersen <
jesper.louis.andersen@REDACTED> wrote:

> On Mon, Feb 12, 2018 at 11:36 PM Vlad Dumitrescu <vladdu55@REDACTED>
> wrote:
>
> [...Checksums...]
>
> Am I misunderstanding something?
>>
>>
> I don't think you are misunderstanding anything. To a certain extent, our
> advocacy is about making a content addressable store be the bottom layer in
> the package manager, and then have a naming layer on top of this:
>
> * Cryptographic checksums have integrity. I don't have to trust the
> package repository and thus the repository can be mirrored. They are also
> way easier to sign.
>
> * Essentially, a package manager should work like git does in the
> underlying layer.
>
> * A package rename does not change its checksum. Rebar[0] doesn't seem to
> be able to understand this.
>
> * A package cannot be removed by checksum. It can be removed by name, but
> if a repository keeps the checksum alive, it is for all senses and purposes
> accessible.
>
> * The checksums are the identifier and the name is simply a human-readable
> attachment. This is important since it avoids a lot of the social
> interactions which occur on top of packages and decouples it from
> technicality to some extent.
>
> * You can easily create name spaces on top. This is highly important as we
> can see in many cases: You may want company-overrides, you might develop a
> package in your own namespace as a fork, you might prepare to take over an
> official package on the side and only flip the name at a later stage. And
> you can easily use a name such as racoon twice if need be.
>
> * The scheme amends itself to something like Conex[1], in which you don't
> have to trust the package repository. Conex also makes the distinction
> between package authors and repository janitors. The latter should have the
> ability to override certain aspects of packages (for instance version
> compability rules) without altering the underlying source code (such that
> it is still verifiable).
>

Thank you for the detailed explanation. I was looking at it from the human
user's perspective.

best regards,
Vlad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20180213/3e072385/attachment.htm>