Longstanding issues: structs & standalone Erlang
Fri Feb 17 08:01:02 CET 2006
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
More information about the erlang-questions