[Mono-devel-list] Looking for people to do Mono/autopackage integration
Miguel de Icaza
miguel at ximian.com
Thu Jul 28 11:52:47 EDT 2005
> > 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?
Raise the bar in the state of art of Linux installation.
> 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
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.
> 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.
Well, Ximian's business was largely managing software installation and
all of its related angles as part of its red carpet product, so am not
terrified by this.
Certainly doing a general purpose tool for all kinds of software (native
c, dependencies, mix of code) is needed, and I think autopackage fits
nicely in this area.
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.
> 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.
Such a document would be invaluable.
My feeling is that autopackage focus is in adapting existing software
which is prefix-designed to be relocatable. 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.
What I would like to do is break with the prefix tradition.
> 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.
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".
The advantage of this is that we could distribute cross-platform bundles
that would work on OSX and Linux.
The "dmg" problem would be handled by a mime-type handler, so am not too
worried about that.
> Most software does, in my experience, even for trivial things like menu
Yeah, this might have to live in a Mono.InstallationServices dll.
> 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.
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'
More information about the Mono-devel-list