RFC: Single Windows Installer

From: Ryan Pavlik <abiryan_at_ryand.net>
Date: Tue Jun 10 2008 - 08:03:35 CEST

Hey folks! I've been meaning to unify our three Windows installers into
a single one for quite some time, and AbiSource Corporation B.V.
recently provided a kick in the pants for me to do so. As you can see
in my last couple commits, I now have all the installer bits to package
the plugins in the main installer. I have not made this the default,
however, as I wanted to just make sure everyone's opinion was being heard.

I'm pretty pleased with how it turned out - we can now specify a default
set of plugins, so if a user just keeps pounding the next button in the
main Abi installer, they automatically get the ODT, WPD, OOXML plugins
and a few more that are useful to the general populace and reasonably
well-behaved. This is similar to common packaging on Linux, including a
clump of plugins if not all of them.

It also simplifies the user experience beyond having a basic set always
available - if a user needs a particular function they don't need to
figure out if it's in the main installer or one of the add ons.

The plugin names in the installer are now also localizable, as a nice
little side effect. In fact, if our translators could look at the files
in abiword/src/pkg/win/setup/NSISv2/lang and translate even just what's
there from before, there have been a least a few untranslated strings
for some time now. (Somebody should add gettext support or
compatibility to NSIS...)

Downsides? Well, the single installer is now larger, since it includes
all the plugins. It's not much larger, though - currently checking to
see the exactly numbers, but the whole thing without stripping the Abi
binary was under 8 megs, and last time I stripped abiword.exe I saved 2
megs in the installer.

The other downside is that our list of components is now really long.
I've cleaned up the other options to reduce the number of components
(who wants to associate with awt but not abw or zabw?) and I'm looking
into other ways to improve it. If anyone knows how to start a part of
the component tree collapsed (so the user just sees the categories if
they don't choose to drill down) in NSIS, please let me know.

This is mitigated by the fact that the installer profiles (Typical,
Full, etc) are well-set and do a good job picking stuff for the "average
user" but it's not ideal. That said, I feel the benefits probably
outweigh the downsides, and I'd like to propose that I commit the last
patch (turn this on by default and have "make distribution" build the
plugins too) to switch us to the unified installer prior to 2.6.4.
There are some source tree cleanups that could be done here too
(removing all old NSISv1 stuff from the tree). This whole thing can be
forward-ported to trunk - a "copy and paste" of the whole pkg directory,
with some fixes by me afterward to account for the new directory layout
(currently broken in the trunk packaging).

So - questions, comments, concerns, words of praise for fishfood?

-- 
Ryan Pavlik
www.cleardefinition.com
#282  +  (442) -  [X]
A programmer started to cuss
Because getting to sleep was a fuss
As he lay there in bed
Looping 'round in his head
was: while(!asleep()) sheep++;
Received on Tue Jun 10 08:03:52 2008

This archive was generated by hypermail 2.1.8 : Tue Jun 10 2008 - 08:03:52 CEST