Longstanding issues: structs & standalone Erlang
Wed Feb 15 06:11:21 CET 2006
Björn Lindström wrote:
> As for the rest, I always get suspicious when people make
> programming language specific package managers that tries to
> do what the distribution does already.
Exactly. And this is all too common in many languages:
- Maven and JavaStart in Java,
- PEAR in PHP,
- RubyGems in Ruby,
- Python's site-packages,
and also in plugin-based applications, such as Eclipse or
It seems that all those home-made specific packaging systems were
created only because of the lack of a common packaging system on
Windows. But they are superfluous on all Linux distributions I
know of, for instance.
I am running Debian, and I want to use only Debian's packaging
system, not one packaging system for every language or for every
application that would clutter my system with unmanageable
> To me, it's much more attractive with a system that can easily
> be hooked into dpkg, ports, RPM, or whatever.
I completely agree. Packaging concerns must be left OUT of the
For instance, Vlad Dumitrescu's proposal to bury packaging /
installation code deep inside the implementation or Erlang is a
bad idea for that reason: it would have to be patched / disabled
on every platform that has a packaging system, to avoid it to
interfere with the platform-managed packages.
If anybody has to create a new Erlang-specific packaging system
for platforms without one, please do it as an additional,
> On that, you could build systems for turning out pre-packaged
> versions of the program for various platforms, including MacOS
> X single-file applications, Windows installers, Debian
> packages/repositories, or whatever.
> So basically, we want a build script that just picks out what
> it needs from Erlang/OTP and the program, puts it in a
> directory structure, and then lets the back-ends for the
> various platforms do their thing. Back-ends for .deb, RPM,
> MacOS X type application bundles and some sort of Windows
> installer program seems like a good first set of goals to me.
> Of course it would also need to support packing up the program
> separately, depending on a separate installed runtime system.
Having automated tools would be very nice.
But an easier goal would be to define a POLICY for Erlang
development, to make packaging easier. Usually, developers and
packagers are different persons. The problem is for developers
to make packaging easier to packagers.
For instance, I propose the following rule:
"Any Erlang application that uses other applications or languages
(e.g. that includes C code) must use Autoconf and Automake."
Then, and only then, it would be possible to automate the
The OTP design principles are a good start: they define a common
directory hierarchy, etc. But they should be extended.
For instance, the Release file format (.rel) should be extended
to allow the declaration of optional dependencies (e.g. "sasl
can be used if it is installed"), dependencies to ranges of
versions (e.g. "stdlib >=1.12"), conflicts, etc.
Debian's packaging system is a good source of inspiration to
improve expressiveness of dependencies in release files.
And to install only parts of Erlang/OTP according to the needs of
specific apps, the solution on Debian is quite straightforward:
we should split the "erlang" and "erlang-base" packages into one
package for every app, with the right dependencies between those
E.g. the "os_mon-erlang" Debian package would have the following
Depends: kernel-erlang (>= 2.10), stdlib-erlang (>= 1.13)
Recommends: sasl-erlang (>= 2.0)
Pr. Chiba Shigeru Group
Dept. of Mathematical and Computing Sciences
Tokyo Institute of Technology
More information about the erlang-questions