Longstanding issues: structs & standalone Erlang

Romain Lenglet rlenglet@REDACTED
Wed Feb 15 09:43:45 CET 2006

> > E.g. the "os_mon-erlang" Debian package would have the
> > following dependencies:
> > Depends: kernel-erlang (>= 2.10), stdlib-erlang (>= 1.13)
> > Recommends: sasl-erlang (>= 2.0)
> Could you please explain how is this to work in practice
> without somehow making the runtime aware of this mechanism? I
> don't get it.
> Suppose I have an app A1 that requires stdlib >= 4.13, and an
> app A2 that requires stdlib <= 4.12. Both of those can run
> with kernel >= 4.3
> Now if A1 and A2 are standalone applications, it will work,
> because they will have separate startup scripts that will
> reference the correct stdlib in the code path.
> But if I start my Erlang node (that references stdlib 4.15)
> just to try things up, how would I make sure only A1 and not
> A2 is available, unless the runtime is aware of these
> dependency declarations?

In Debian, there is only one version of every package that can be 
installed at one time (according to the package name).
For instance, in my proposal above, only one version of stdlib 
and kernel can be installed at a time. So, depending on the 
installed version of stdlib, either A1 or A2 can be installed 
(not both).

This can be solved by setting up a chroot, where another version 
of stdlib can be installed, to install the other app. Packages 
can be installed/deinstalled/upgraded/downgraded separately in 
the system and in every chroot. And the Erlang system would have 
no problem finding the right version of apps: only one version 
would be available in every chroot.

In Debian, it is also allowed to put part of the version number 
in the package name. So we could have two packages: stdlib-4.12 
and stdlib-4.13. Those could be installed simultaneously. 
(Although usually, only the major number is added to the package 
The latter mechanism is usually used only when a big "jump" in 
functionality has happened, e.g. between libc5 and libc6.
The problem is that the Erlang system cannot be able to choose 
the right installed version.

The problem with both the standalone apps and the chroot 
solutions, is that some applications will be installed several 
times with the same version (e.g. stdlib, sasl or kernel), which 
wastes space. And an additional problem with the standalone 
solution is that it makes it difficult to upgrade included 
applications without upgrading the whole standalone application, 
which wastes bandwidth.



More information about the erlang-questions mailing list