[Mono-devel-list] Looking for people to do Mono/autopackage integration

[Mike Hearn]

Miguel de Icaza wrote:
> For those programs that do not require native libraries, we could
> probably generate a Mono-based installer that can use console or
> Windows.Forms based installations.

Well, I can see why this would be tempting for you but my advice is don't:

a) You'd be rewriting what already exists, for what benefit?

b) Autopackage is already being used by projects, it has small but
    rapidly growing mindshare - it'd be nice to have some standardisation
    across projects so users get a consistent experience

c) Writing installers *sounds* easy, but by the time you've made it
    work on N^2 distros, fixed all the bugs, added digital signatures,
    a nice user interface, support uninstalling/upgrading native packages
    if they already exist etc etc, it turns out to be a lot of work.

Autopackage has been in development for a long time now. It is true that 
a lot of this time was spent 'fixing' the design decisions of the GCC 
and glibc people, which I guess .NET does not suffer from, but still ... 
much of that time was also spent writing the bootstrap code, 
documentation, su/sudo wrappers, GTK+ and Qt based GUIs, integrating 
LZMA compression, getting professional artwork etc.

> 	* Write the code that installs software: should this be
> 	  an executable program, or should it be a package format 
> 	  with a special extension that a "minstall" command can
> 	  process?

With autopackage it's both, but leaning more towards the former. For 
maxiumum ease of use, the first time you run them they'll download and 
install the runtime code itself. Then after that, you can just click on 
.package files to install them. This flexibility is why we were able to 
switch to a much improved compression algorithm for the 1.2 release, for 
instance.

> 	* Applications that use this process should probably follow
> 	  the Application Guidelines, but take things a step further:
> 	  be completely relocatable and break with the Unix tradition
> 	  of prefixed-based configurations.

Autopackages are always relocatable and we provide an easy way to 
install stuff to $HOME if you don't have the root password. We provide 
simple kits you can integrate with the program to make them relocatable, 
as well as complete documentation on how to do it.

You can see this in action here:

    http://autopackage.org/flash-demo-install.html

This code should be in glib really, but the independent kits are useful 
for now.

> 	  I would go as far as advocating the creation of a standard
>  	  to create OSX-like bundles for Linux and encourage the
> 	  various desktop efforts to include support for bundles.

This has been discussed many times on autopackage-dev, and we have 
invented at least three different ways of implementing appfolders on 
Linux. Some require integration with GNOME/KDE, and other techniques are 
fully backwards compatible with existing desktops.

So far we've never implemented it - it turns out that basic stuff like 
being able to get root on a wide variety of distributions in a fully 
graphical way took up all our time so far. However, it was designed from 
scratch to support multiple user interfaces and we already have fairly 
complete blueprints for not only the current wizard-style UI but also an 
apt-get style command line UI and a MacOS X style bundle UI.

> The first addresses software that requires it to be adapted to the
> target system, register itself somewhere or modify some system files;  

Most software does, in my experience, even for trivial things like menu 
entries.

> A prototype should not take longer than a day.

Heh, famous last words ;)

The autopackage prototype only took a week, and that included 
uninstallation, verification and dependency checking. Turning it into a 
product took three years. There's no need to re-invent the wheel here.

thanks -mike