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

[Mike Hearn]

> > a) You'd be rewriting what already exists, for what benefit?
> 
> Raise the bar in the state of art of Linux installation.

That's certainly a worthy goal, but I'd like to think we already did - 
easy to use one click installs are something we put a lot of effort 
into. If you haven't watched the Flash demo, I'd recommend it:

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

> Am thinking of something that normal users can use, not something that
> copes with every possible angle of software dependencies, but going for
> a simple OSX-like setup.

Well, it's not drag/drop, but it *is* just as simple:

* Click on a link in a webpage
* Click "Open" in the firefox file download dialog
   (actually you can tell firefox to always open this filetype)
* It downloads ... there is a simple confirmation window:

   http://autopackage.org/screenshots/newshots/gtkfe-intro.png

* You click Install and then enter your password (or not):

   http://autopackage.org/screenshots/newshots/autosu-ask.png

* That's it. You get a summary screen at the end:

   http://autopackage.org/screenshots/newshots/gtk-yaydone.png

The user doesn't have to think about dependencies, or install paths, or 
anything really - the only decision to make is "Do I know the root 
password" and this is easy, either you do or you don't. On MacOS X you 
must make some more decisions:

* Do I click the app right now, while it's inside the DMG?
* Or ... do I drag it to the dock?
* Or ... the /Applications directory?

Actually only the last one is correct, but that's something you just 
have to know. So I don't think the autopackage UI is complicated.

> What am suggesting is something Mono-specific for small applications
> that can take care of average applications being developed.  Think about
> Perl, Ruby and Python's frameworks for doing software installation: they
> are not frameworks for doing *everything* but they can do a pretty good
> job for *most* of their software.

Sure, but your typical Mono app does have dependencies: the Foo# library 
bindings if nothing else. Well, you could ship them all as part of the 
Mono platform and that'd work, but "bleeding edge" apps would still have 
problems. A large platform combined with automatic graphical dep 
resolution for very new libraries:

   http://autopackage.org/screenshots/newshots/gtkfe-retreive.png

seems like a nice balance.

> Such a document would be invaluable.
> 
> My feeling is that autopackage focus is in adapting existing software
> which is prefix-designed to be relocatable.  

Sure, we try and make this easy because autopackages are relocatable as 
a rule. But that's just an artifact of most C programs not being so, 
there's nothing C specific about it.

> Where can I find the
> documents/tutorials for this?  We might want to change Mono's installer
> to use something like this, as it currently breaks for 2.x uses. 

Actually, this document is for an older version:

    http://autopackage.org/docs/binreloc/

The CVS version of binreloc is simplified considerably and can generate 
different styles of code (eg, raw C vs glib style). It also has less 
bizarre memory management semantics. Unfortunately it's not documented 
yet, but the basic theory is the same: provide convenience functions for 
finding your own path, getting the prefix from it, and then appending 
other paths (all in one function if you like).

> What I would like to do is break with the prefix tradition.

Yes, me also. That's why we have it as a rule.

> What I care about the most with bundles is being compatible with OSX in
> as much as possible.  Am talking about the file system structure, not
> really the actual "dmg" image, ie "Chess.app".

Given that bundles need to be customised anyway, for instance to have 
Aqua compatible artwork, I'm not sure it's worth trying to make Linux 
apps the same right now. It'd be better to provide an installer EXE for 
Windows, an autopackage for Linux and an bundle for MacOS X.

> The "dmg" problem would be handled by a mime-type handler, so am not too
> worried about that.  

Right. But MIME type handler for GNOME 2.10? or GNOME 2.8? Or KDE 3.x? 
Or all of them?

> Yeah, but like I said, autopackage is for seriously complicated apps;
> Am thinking it more for pure Mono apps which have much less dependencies
> and we can safely assume `Mono is in your path'

Well, not really, right now autopackage is used for really quite simple 
apps packaging-wise: Gaim, Inkscape, AbiWord: none of them are too terrible.

I tell you what. How about I try and package a Mono app tonight, and I 
will show you how trivial it really is. There's a quickstart document here:

    http://autopackage.org/developer-quickstart.html

which shows you all the basics in one page, and it also covers basic 
advice like "don't depend on CVS versions of unstable libraries" ;)

Ignore the C++ warning, this is relevant only for the stable 1.0.x 
series, but we have much improved C++ support in CVS that will make 
dealing with the ABI change fully automatic.

I will see if I can send you (and the rest of mono-devel) an example 
specfile and installable package that you can test by the weekend. Then 
if you still think it's too complicated, we can find out why and how to 
fix it. Deal?

thanks -mike