Longstanding issues: structs & standalone Erlang

Romain Lenglet lenglet@REDACTED
Wed Feb 15 11:07:12 CET 2006

> > An alternative is to have a packaging system that allows you
> > to have multiple parallell installations of something, under
> > different prefixes.
> So if I understand things correctly, nothing is simpler than
> before :-)
> These beasts work with applications, but if I am using Erlang
> as a scripting language or from the shell, then they are of no
> use.
> If I start with just "erl", I might be very surprised that
> some package I just installed isn't visible or working,
> because the default erl isn't the one the package wants.

Anyway, the general problem of installation of multiple versions 
of a package (the "DLL Hell") is difficult. Nobody really has a 
solution. Only Microsoft has introduced versions in DLLs / 
assemblies, i.e. dependencies are explicitly to specific 
versions of DLLs:

The equivalent solution in Erlang would be to always specify the 
version of a module when using it, and to modify the runtime 
accordingly, e.g.:
{io, '2.1'}:format("hello~n", []).
Problem are: 1) that looks ugly in Erlang, 2) module versions are 
optional, 3) modules are not a unit of installation / 
configuration (applications are such units, and it is their 
versions that are important), 4) how to do dynamic code updates?

In Linux distributions, simultaneous installation of different 
versions of a package is not allowed. And when this is 
absolutely necessary, e.g. for libc5 and libc6, then the version 
number is added to the package name and to installed files.
An equivalent solution in Erlang would be to add version numbers 
into module names, e.g.:
'io-2.1':format("hello~n", []).
Ugly, isn't it?

Acceptable solutions to the multiple-versions-problem are: 1) 
chroots on Linux / BSD / anything with a package system, 2) 
self-contained, self-installable applications on other 

But I think that this specific problem of multiple versions only 
rarely occurs (?), so we should not focus on it.


More information about the erlang-questions mailing list