[Mono-devel-list] Looking for people to do Mono/autopackage integration
m.hearn at signal.QinetiQ.com
Thu Jul 28 05:21:55 EDT 2005
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
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
> * 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:
This code should be in glib really, but the independent kits are useful
> 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
> 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.
More information about the Mono-devel-list