Longstanding issues: structs & standalone Erlang

[Romain Lenglet]

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 
NetBeans.

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 
files.

> 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 
Erlang implementation.
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, 
optional software.

> 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 
packaging process.

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 
packages.
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)

-- 
Romain LENGLET
Pr. Chiba Shigeru Group
Dept. of Mathematical and Computing Sciences
Tokyo Institute of Technology