Longstanding issues: structs & standalone Erlang
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
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