[lokisetup] Announcing MojoSetup.

[Ludwig Nussel]

Ryan C. Gordon wrote:
> There are lots of other attributes in setup.xml that were clearly 
> special cases that would be better in installer-specific logic, rather 
> than forever locked into the config file schema and bloating the 
> installer itself. Not to mention some attributes needing to be "true", 
> some needing to be "yes", some just needing to exist...the schema and 
> the interpretation of it had its share of problems. A scripting 
> language, even one as liberal as Lua, tends to enforce correct syntax 
> much better.

Well, there was a dtd file for setup.xml you could enforce pretty
much everything too. That's one of the main features of xml.

> Also, libxml2 turned out to be _insane_ for file size if you have to 
> statically link it: for example, this test program...

Not that I am a big fan of xml but I bet you could write a
not-so-generic, non-validating xml parser with less code than
libxml2.

> 1) You can have a standard "package format" (filename.mojosetup or 
> whatever), that you could distribute if you expect MojoSetup to be 
> preinstalled on the system. That gets around the 
> executable-bit-on-downloads issue if distributions show up and install 
> MojoSetup...but this isn't required.

... which means it won't be used. You'd really need to enforce
vendors to use such a package format. However, as long as you allow
vendors to 'customize' the installer by hacking the 'engine' and
ship such modified binaries any attempt to have a package format
that can be installed with an external application will fail.

> 2) You can put your data in a zip file, and append it to the installer 
> executable.

That's cool as zip could be defined as package format. The prepended
installer would be optional.

> When I shipped a Linux version of Candy Cruncher (a casual game from 
> pyrogon.com), I had loki_setup with a statically linked GTK+1 UI, and a 
> statically linked curses/dialog UI for the installer, wrapped in a 
> makeself script. I got complaints from dial-up users that the 
> installer's download was bigger than the installed game. In MojoSetup, 
> the GTK+2 UI currently adds a whopping 14 kilobytes to the download 
> _before compression_. The stdio UI is 6.

Well, if you decide to add a statically linked mojosetup gtk1 GUI
you'd have the same problem as with loki_setup :-)

> We could probably drop in a 
> KDE, SDL, and wxWidgets implementation for about the same space and let 
> the installer sort out the best plan of attack on the end user's system. 

Please, please don't. Just resist the wxWidgets trolls. KDE also
doesn't need a separate gui. GTK2 will just work fine. 99.99% have
that installed anyways due to Firefox etc. A C++ GUI would only work
when provided by the system rather than the downloaded installer due
to binary compatability issues. Unless you ship the C++ libs as well
which kind of defeates the purpose of your plugin system.

> - All strings are UTF-8 internally. Unicode and localization were 
> considered from the start. All translations are kept in a single text 
> file (a Lua script, actually), so you don't have to fight with GNU .po 
> files.

I don't think it's a good idea to give lua scripts to translators.
There are very good tools to aid translating po files, like kbabel
or emacs. You could probably just compile and merge the .po files
you get from translators into a lua script for the actual installer
though. SUSE uses a mechanism like that to have .desktop files for
the distribution translated for example.

> - There is a "rollback" mechanism. Barring catastrophic disk failure, 
> failed installations can undo everything they wrote to the filesystem, 
> including restoring preexisting files that were overwritten during the 
> install. The installer even makes an earnest attempt at cleanup and 
> rollback if it is crashing with a segfault.

nice :-)
 
> - As you would expect, the installer can use CD and DVD discs (and USB 
> keychain drives, Samba shares, etc) for installation media, but it can 
> also use data stored on a web server. You can specify files to be 
> obtained at runtime over HTTP or FTP, which MojoSetup will do before 
> starting the actual install loop. This is useful for shipping an 
> extremely small package that gets the user to a UI as fast as possible, 
> then downloads just the optional bits they choose to install...this also 
> allows a vendor to supply updated installer packages on their website 
> without having to repackage the installer itself.

I guess vendors find that totally sexy. IMO installers that
automatically download crap from the internet themselves are
horrible. I want to be able to install that thing I downloaded
yesterday to also work tomorrow when the vendor's web server went
out of service or I don't have an internet connection (LAN party!).
Also if you want to install the application on more than one system
it sucks to have the installer download it multiple times.

I'd also make some sort of authenticity check mandatory in order to
prevent man in the middle attacks. Ie enforce specification of md5
or sha1 sums for files in the config file.

> - No autoconf/automake nastiness, we're using CMake (thanks to KDE for 
> moving to that and making it a viable tool).

Means you can't even compile mojosetup on the pretty recent openSUSE
10.2 due to some macro package that is not yet in cmake 2.4.3 but
only in 2.4.6 ... o_O

> The UI is really rough at the moment and there are some other bugs, too. 
> There are some obvious features of loki_setup that aren't yet available 
> in MojoSetup, and the documentation is completely non-existent at this 
> time...but it gives you an idea of what I'm going for here.

For example a database of installed applications and files and an
update mechanism. At least the former is a shop stopper feature
IMHO.

After a glance at the source code it looks like you also allow shell
script hooks. Wouldn't it be better to enfoce lua scripts instead?
With lua I guess you could intercept file modifications so vendors
can't do arbitrary stupid things behind the installer's back.

I noticed that you include zlib and bzip2 source code. Is that
really necessary? Even if you want to link them statically you can
just take the system provided libraries.

cu
Ludwig

-- 
 (o_   Ludwig Nussel
 //\   SUSE Labs
 V_/_  http://www.suse.de/
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)