[erlang-questions] What problem are we trying to solve here? [was Erland users group [was re: languages in use? [was: Time for OTP to be Renamed?]]]

[Garrett Smith]

On Mon, Feb 17, 2014 at 11:14 PM, Richard A. O'Keefe <ok@REDACTED> wrote:
>
> On 18/02/2014, at 3:36 PM, Garrett Smith wrote:
>>
>> $ git clone git@REDACTED:anthonyrules/super-cool-repo.git
>> $ cd super-cool-repo
>> $ make check
>> $ sudo make install
>
> Please.  NO!  I can do this inside VirtualBox, but generally
> sudo is poison.

I'm not suggesting this as the one and true way to manage Erlang
software, goodness.

If a Makefile is properly implemented, you should also be able to do this:

$ make DESTDIR=pkg install

as non-privileged user and effectively create an isolated image of the
installed files.

This is what package managers typically use. Even if the "install"
(i.e. file copy) mechanism is implemented by something else, I'd hope
to see a canonical Makefile wrapper (as is commonly provided with
rebar).

My point was only that packaging, testing, CI, etc. is certainly
supported through a git based source distribution scheme.

> Anything that expects people to trust an unknown makefile not
> to do evil things while installing had better have some
> really *serious* security and authentication on it.

Certainly. I wouldn't trust anything unknown either. This is why, e.g.
Arch packages are signed by their maintainers, who must be explicitly
authorized as trusted.

> One of the really great things about the R repository and
> package management is that it works *without* needing any
> special privileges.

My preference with Erlang applications is to take the sources and
create a stand along image, which can be installed anywhere on the
system, either in a privileged location or locally. I don't like
maintaining repositories of shared libraries in user home directories
(e.g. .gem, .m2, and so on) as these introduce yet another painful
dependency graph problem, and inevitably end up colliding in strange
ways with system packages.

This seems to be the prevailing pattern anyway, which might explain
why the many efforts to spawn Erlang package repositories have not
taken off. I might have missed something there though -- I know
there's been a lot of activity in this area over the years.

Garrett