Re: [DotGNU]Concept: Box files

[Peter Minten]

Rhys Weatherley wrote:
> 
> Peter Minten wrote:
> 
> > Java has jar files that make it possible to send a program in a nice small
> > package over the internet and to run it straight from that package without
> > unzipping or anything. This maybe useful to IL bytecode programs too, 
> > especially
> > since IL programs tend to have extras like resource files that need to be 
> > send
> > with the executable.
> 
> Resources can be bound to the IL executable during link time,
> so that there is only one file to be distributed.  This is
> already supported in pnet's toolchain.

Right, one type of support files less to worry about :-).

> There's still the issue of distributing a .exe with any .dll's,
> scripts, docs, source, etc, that it may require.

Hmm, docs are a separate concern too. The docs will be another separate part of
a box (besides binaries, source, config and support files).
 
> There are two separate problems here: installing an IL app
> locally, and downloading an IL app for immediate execution.
> 
> In the first instance, it sounds like you want some kind of
> package format, similar to .rpm or .deb.  Rather than inventing
> yet another packaging system, it may be best to reuse one of those.

I disagree.

A problem with rpm and deb is (in my limited understanding) that they are not
flexible in installing, they always want to install in usr or some /usr like
directory like /usr/local or /usr/share. This creates problems when you say want
to install the gtk-sharp source debs in your home dir. Also rpms and debs *need*
to be installed to be run and since the install dir is mostly /usr or /usr/local
that creates new permanent files. Of course that's not a problem if the root
keeps the system tidy, but many hobbyist roots aren't, creating a dirty system. 

With boxes you are able to install a program on trial in a temp dir, the
binaries, support files and configuration files are copied into temp dirs and
removed after use. Though this increases the load time of an application it
helps keep the system clean of applications a user just wanted to try out but
forgot to remove. 

Another big advantage of the box system is separation of concerns ;-), support
files are another concern as binaries and should not automatically be treated
equally. The box system gives users the option to install or not install support
files, but the binary needing them will still run. For configuration files the
install choice is also useful and can even be extended onto override, override
means that the installed configuration files are temporarily hidden and either
the installed config files or the standard files are copied into a temp dir and
used, this is very useful for testing different configurations.

And let's not forget the Warehouse search system which is an improvement over
the debian way. Using Warehouse you can find and download files you need in a
secure way from your local package manager, you don't need to specify a download
location or anything.

> Perhaps one of the Debian gurus on the list could tell us how
> .deb's can be adapted to install portable executable formats.
> I believe that Andrew Mitchell already solved this for the
> pnetmark Debian package, which is a pure-IL application.

Debs are without any doubt a good idea. We should definitely distribute debs as
well as boxes.

> In the case of "download and run" scenarios, the assemblies
> already act as a kind of .jar file, so I'm not sure that a
> .box format would really help us.

Can support files like mp3 or jpeg be build into the assembly? With the box
system these files can be build in a simple package that is like an executable
for the user (since the user can invoke the binaries in it with a single command
'box --run file.box').

Greetings,

Peter