Longstanding issues: structs & standalone Erlang

[Fredrik Thulin]

On Wednesday 15 February 2006 09:11, Vlad Dumitrescu XX (LN/EAB) wrote:
...
>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
...
> 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?

I'm not able to give answers as to how the Debian packaging systems 
would solve this problem, but I would imagine that you can't have two 
versions of the same package (stdlib-erlang) installed at the same time 
(when required, they seem to split such things up into two different 
packages that can co-exist under different paths).

An alternative is to have a packaging system that allows you to have 
multiple parallell installations of something, under different 
prefixes.

  $ ls -d1 /pkg/erlang/*/lib/erlang/lib/stdlib*
  /pkg/erlang/R10B-6/lib/erlang/lib/stdlib-1.13.8
  /pkg/erlang/R10B-9/lib/erlang/lib/stdlib-1.13.11
  $

If I were to try something out, and it said it required stdlib 1.13.8, I 
would use the Erlang/OTP in /pkg/erlang/R10B-6/. Conflicts are 
conflicts. You must either resolve them by making it possible for the 
two different versions to co-exist, or you must choose which one you 
want - you can't have both installed in the same place at the same 
time.

I might have missed something, but I don't beleive the Erlang way of 
specifying runtime dependencies allow you to say that you require 
stdlib >= 1.13.8, even though your application really would work with 
anything >= 1.13.8 (because that's when function 'x' was added or 
similar), but instead requires you to say that this particular version 
of the application you want to try or requires stdlib = 1.3.8, because 
that's the exact version the application developer has tested the 
application with, and therefor the only one you can be sure works.

/Fredrik