[lokisetup] setup v2 (was lokisetup for dummies)

[Sean Middleditch]

On Sat, 2004-01-03 at 21:54, Ryan C. Gordon wrote:
> > To say the least, it wouldn't be anywhere near difficult to write an
> > installer builder with a nice GUI that wraps all the low-level details. 
> > One could simply save XML files detailing available options,
> > dependencies, and so on, and then simply "compile" that into the
> > necessary scripts and files for a .package file.
> 
> I'm going to go out on a limb here and demand _less_ flexibility.
> 
> What I want from an installer, in order of importance:
> 
> 1) Works everywhere it needs to without bells and whistles.
> 2) Has the absolute _smallest_ disk footprint possible.
> 3) Doesn't take a PhD to make an installer for.
> 
> #1 is broad, I know, but I think that all this talk of different UIs is
> somewhat frivolous if it adds to the disk footprint at all. Ideally
> there's a bare-ass minimum GUI of some sort for the average person, and
> a text-based installer (that can be compiled out entirely) for things
> like dedicated servers where the user almost certainly won't have X11.
> If we're statically linking GTK+, then it really might be worth writing
> some extremely minimalistic toolkit if it'll save a megabyte, but that
> might be going too far once the actual link size is evaluated.

Autopackage doesn't require the installer to be part of the download. 
Instead, the .package files have very small stubs which can fetch and
install the Autopackage system if it's not already installed.  Of
course, the idea with the installer system being discussed is that is
already be installed, which Autopackage presumably would be on all major
distributions if it can become popular enough.

> 
> Pyrogon, the Candy Cruncher guys, said that they had some very
> interesting statistics on the number of downloads that were
> disconnected/cancelled halfway through the transfer. The assumption is
> that these people were on dialups and either dropped carrier, or got
> bored and hit Cancel. Candy Cruncher is a few megabytes download. The
> download of the linux version is 25% installer. And people wrote in
> complaining about this. Some of us don't have the luxury of shipping
> product on a CD-ROM, and I suspect most of us have the luxury of
> broadband, too. Dialup is friggin' painful for anything over a few
> megabytes.
> 
> On the other hand, an external application that generates the installer
> from start to finish (a "wizard" app, if you will) can be big and bulky
> and beautiful, since it doesn't need to be distributed to the end
> user...and would make the whole process of building installers and
> patches suck less and be significantly less error prone...I can't count
> the number of screwups that were made in ut2003 patches that a nice
> drag-and-drop GUI would have prevented, not to mention the man hours
> spent building installers and patches in the first place. Obviously this
> is totally seperate from the main discussion, but it's really really
> really desirable to me to have this at some point, so I wanted to throw
> it out there again.

I agree.  Packagers and distributors shouldn't need to be programmers. 
A good GUI package/patch creator can wrap any system, if well designed,
and let quick and simple packages be made with minimal pain, while
allowing more complicated packages to still be possible using for
advanced(and complicated) tools.

> 
> For the installer itself, less is more. I'm all for ditching the XML,
> setupdb, the Dialog UI, scriptability, etc. I don't expect this will be
> a popular position, but I honestly think it is best.

Again, this simply isn't an option for some applications.  A packaging
system that's incompatible with everything else and only works for a
very, very small class of applications isn't going to be very popular
nor useful, not to mention never available pre-installed on users'
machines.

Letting the installer support advanced features doesn't mean you have to
use them.  If you don't want any scripts in your application's package,
don't put any there.  An installer should be capable of handling all the
basic needs with a complete minimum of fuss, but allow flexibility thru
scripting or whichever other means an application may find necessary.

> 
> --ryan.
> 
> 
-- 
Sean Middleditch <elanthis at awesomeplay.com>
AwesomePlay Productions, Inc.