Longstanding issues: structs & standalone Erlang

[Fredrik Thulin]

On Thursday 16 February 2006 16:17, Douglas Philips wrote:
...
> And I never said you had to log in to each machine, just that the
> packaging install commands had to run on each machine.
> As long as the installation process does not require interaction with
> a human, it can be automated and handled with a cron job.
> That doesn't require (though it would be nice if it used) the native
> OS packaging.

I agree. I beleive though that packaging of Erlang applications should 
be possible by the people who have already packaged thousands of other 
applications in one packaging system or another - it should not be done 
'in advance' like with CPAN. The developers of an application should 
express it's dependencys, not enforce a certain packaging.

I have this opinion based on that all the attempts of such pre-packaging 
(or otherwise non-standard installation procedures) I've seen have 
caused me and my colleagues alot of extra work in making buildit 
modules for those applications - _none_ have made it simpler. This 
tells me that the same goes for all people involved in creating OS 
distributions, even though I realize that this is not true for people 
only managing a single (or a few) installations.

(as a side point: buildit is not the native OS packaging, we always use 
a distribution underneath, although we install all the applications we 
really care about using buildit).

> > In both these cases, the common part of the problem is the
> > packaging. You need to distribute binaries, or instructions about
> > how to generate binaries in some way. It is impractical to have to
> > have one way to do this for regular programs (like KDE, the
> > Erlang/OTP installation, your other favourite applications) and for
> > programs that install "inside" any of the others (like CPAN for
> > Perl, or some Erlang way to install Erlang applications).
>
> You almost had me there. There is no reason why the "inside Erlang
> way" couldn't in fact call out to the underlying OSes facility.

I'm not totally sure I understand what you mean, but if you mean that 
"./configure; make; make install" would do a lot of Erlang-stuff behind 
the scenes, then I have no objections to that.

> But it is worse than that, because usually installing new software
> requires special priveleges (root, Administrator, etc.) and that is
> not likely to be available when some user wants to have a new Erlang
> module/application installed RIGHT NOW.

It won't be available through the "Erlang way" either. If Erlang/OTP is 
installed somewhere outside your home directory (or similar) by the 
system administrator, you can't modify Erlang/OTP. The only solution is 
to make it possible to have Erlang/OTP installed by someone else, and 
still install Erlang applications/librarys somewhere where you have 
write access. Erlang/OTP should of course continue to be installable 
wherever the user wants too.

...
> Again with the ignoring Windows. Look, I am not unsympathetic to
> ignoring windows, but I think that would disparage a significant
> number of actual Erlang developers.

I agree. I don't want to ignore Windows, but I have never heard of 
anything like BSD ports or Debian apt on Windows. As far as I know, 
Windows is all about next-next-finish installers that, if they are 
supposed to be downloaded from the Internet, are preferably single-file 
executables.

/Fredrik