[lokisetup] setup v2 (was lokisetup for dummies)

[Sean Middleditch]

On Mon, 2004-01-05 at 14:09, Adam D. Moss wrote:

> I'm still... well... the computer scientist in me likes the
> theory of the universal install-once stubbed package utility, but
> the pragmatic package-maker in me wants a self-contained solution
> that pretty much exactly fits Ryan's criteria of being basic and
> small, and really really working when you run/click it.

That is, of course, the problem.  If you have a mini-installer included
with an app, who is to say it *will* work tomorrow when the next version
of distros come out?  Just about all older apps using loki_setup are
already broken in at least a couple user critical ways (example,
installing menu entries where the modern DEs expect to find them, in a
format they expect it to be in - nobody but an experienced Linux geek
can be expected to find the application binary and create a menu
entry/shortcut to it, but that's what people already have to do).

Allowing the install system to be pre-installed on the user's system
allows us to work around this problem, and any similar future problems. 
I.e., if the desktop menu format changes again, the installer would
simply translate the package's menu entry file if its in an older format
to the new.  (Or, preferably, the installer would generate a menu entry
from the package metadata, which simplifies packaging even further.)  X
and desktop specs are constantly changing lately, making even relatively
new software at least appear to be malfunctioning, if not outright not
working.  If the installer is only in the package itself, this makes the
software impossible to install without serious hacking by the user.

Other possible problems include things like accessibility - will the
mini toolkit chosen for loki_setup2 offer complete ATK integration,
support the user's GTK/Qt theme carefully chosen to handle font size and
color contrast issues, etc.?  Unless you plan on reusing GTK2 or using
Qt4, we already know the answer to most (if not all) of the above is
"no."

Perhaps the best idea is to take a step back and start with a proper
design.  Don't think about the software engine.  Don't think about code
at all.  Think about what the packages need to do.  Design a package
spec, i.e. all the meta-data you need.  Then you can, *optionally*,
include a mini-installer engine with the package, and/or let another
possibly pre-installed engine do it for you.  Users that don't have such
an engine available can use the bundled dinky installer, while users
with an engine can enjoy the benefits of fully integrated system
software.

This can already be done with Autopackage, simply by replacing the
"download and install" stub with a "use embedded installer" stub. 
Autopackage also separates the GUI from the package, so any future
changes necessary will Just Work(tm).  Plus packages can be installed on
systems that can't support fancy GUIs (i.e., if you need to install that
new word processor on a terminal server box 2,000 miles away over a slow
connection, just use the TTY frontend instead of the GNOME frontend).

Again, if your goal is to make things work easy for the *packager*, and
not work easy for the *user*, don't bother packaging your software at
all, because you're already going to be stuck with a user base of people
who are experienced enough to just use a tarball and a README.

Again, if the user can't just 1) insert CD or download file, 2) click
install, 3) play, then it's too hard.  If the user has to spend time
manually configuring binary paths, recreating broken menu entries, try
to get the installer to recognize his newer system software, have some
uber-geek tech support walk him thru the install, or have a friend do it
for him because the installer isn't friendly to his accessibility needs,
then you have wasted lots of time and money for no good reason.

Even assuming an installer *can't* be embedded in a download package, so
what?  I've yet to see a single Linux download that *doesn't* require
some kind of external utility or library that isn't found on all systems
(not the least of which is working accelerated OpenGL, so far as
loki_setup's main domain is concerned), so is having to go grab a
"SoftwareInstaller.rpm" file first going to be a real problem (assuming
that said SoftwareInstaller isn't popular enough to just be
pre-installed) ?  It's a hell of a lot less time and effort than I've
put into working around numerous broken installers that only work
properly on a small handful of outdated Linux distros/versions.  ;-)

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