Longstanding issues: structs & standalone Erlang

[Douglas Philips]

On 2006 Feb 15, at 12:11 AM, Romain Lenglet indited:
> 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.

Well, either things go down a fractured path, and those stuck with  
Windows continue to solve their problems, and those with package  
systems continue to ignore that and use their own, or a different  
solution is taken.

Its hard not to laugh "I want to use only" ... the moral high ground  
is interesting, but its not clear what useful purpose it is serving  
here other than to say that those poor loser Windows users are  
screwed, lucky I'm not one of them! :-)


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

Modules are already a packing concern. I think you meant to say: the  
delivery and partitioning of application pieces (source, beam files,  
whatever) should not be part of Erlang. But it is hard not to draw  
the same conclusions with processes. Why should Erlang have its own  
process system just because Windows is too screwed up to do threads  
"right?" (Or Linux, or whatever). I found it interesting that you  
didn't mention, for example, Perl and CPAN. Of course CPAN is a huge  
success, so that makes it a less juicy target, eh?


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

How does that fit with multiple applications which want to have their  
own dependencies on specific versions of specific modules? Last i  
looked at RPM, that wasn't handled very well...


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

And what of bundles of other Erlang code, such as version  
dependencies on Erlang itself, or OTP?


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

But how does that work when another OSes native packaging doesn't  
have as much expressiveness?


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

Repeat immediately preceeding question.



Yes, it is frustrating that Windows hasn't solved this problem.
But I don't think you can say that all of the home made packaging  
systems are a result of that.
There is a trend for many applications to "phone home" and check, on  
their own, to see if there is a newer version of themselves  
available. Some can be configured even to automatically update if  
there is (I'm not saying if this is good or bad, just that it is).
Perhaps those applications don't do that under Linux* or *BSD simply  
because they really can't do so.
Perhaps a bit less of the high'n'mighty Debian one true way and more  
of: What problems are being solved and is application deployment  
serving those who use the applications, or merely those who package  
them. My sysadmin (well, me) doesn't pay the user (me, again) to use  
the system, the other way around.

(Sorry if this is terse, it is late in my time zone and I hope  
terseness isn't mistaken for a different tone.)

		--D'gou