Longstanding issues: structs & standalone Erlang

[Rick Pettit]

On Thu, Feb 16, 2006 at 10:17:23AM -0500, Douglas Philips wrote:
> On 2006 Feb 16, at 3:04 AM, Fredrik Thulin indited:
> >On Thursday 16 February 2006 01:12, Douglas Philips wrote:
> >>On 2006 Feb 15, at 3:12 AM, Fredrik Thulin indited:
> >>I don't see how you can avoid that, since you have to run the
> >>packaging install commands on each machine, right?
> >
> >Well, no. It is all about _not_ having to log in to each machine.  
> >Either
> >you can have something like cron-jobs that fetches all packages you
> >want installed from somewhere, and installs them, or you effectively
> >execute them from the same set of binaries made available via some  
> >kind
> >of networked file system. This is what we do - we use AFS.
> 
> Yes, I know. AFS was created at CMU. Heh.
> 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.

I prefer cfengine--I use it to avoid "black sheep" servers on our network.
When packages get deployed, cfengine does the work. 

> That doesn't require (though it would be nice if it used) the native  
> OS packaging.

I replace the native OS packaging system (on Solaris anyway) with NetBSD
pkgsrc. When I install software, be it Erlang or other stuff, I build a
NetBSD package (if there isn't one out there already--the packages collection
is quite large these days).

My packaging system doesn't change when the OS does, either. Nor does the
cfengine configuration for building my network of servers.

So all software is consistently deployed, regardless of OS, using the NetBSD
packaging system (regardless of the host OS!) and cfengine (also quite
portable).

I should note that I haven't done much with Windows, only *NIX boxes. I
understand cfengine works on Windows--as for Windows, not sure there is much
support (other than Interix):

  http://www.netbsd.org/Documentation/software/packages.html#platforms

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

I should add that cfengine runs as root and one really must be careful to
avoid shooting themselves in the foot. I wouldn't run cfengine on external
servers, either (only on internal machines behind a firewall).

> Part of the problem is that there is no concept widely promulgated  
> for seperating the OS's packages from the users.
> 
> >I am guessing now, but I think lots of people in the Erlang developer
> >community more or less only care about the Erlang part of this  
> >problem,
> >whilst I want to be able to install Erlang applications in the same  
> >way
> >that I am already installing all the _other_ applications that I
> >(really 'we' at Stockholm university) care about.

That's why I use NetBSD pkgsrc.

[snip]

-Rick