[lokisetup] setup v2 (was lokisetup for dummies)

Sean Middleditch elanthis at awesomeplay.com
Sun Jan 4 15:40:04 EST 2004

On Sun, 2004-01-04 at 14:35, Chunky Kibbles wrote:
> On Sat, Jan 03, 2004 at 06:31:21PM -0500, Sean Middleditch wrote:
> > On Sat, 2004-01-03 at 17:54, Timothee Besset wrote:
> > > Well I didn't know about autopackage existence. Gave it a brief review, 
> > > they have a nice website. Anyone have experience with it, care to share 
> > > it? In what ways does it compare to loki_setup?
> > > 
> > > After a quick review through the website, it lists a bunch of useful 
> > > functionalities, but it has the design flaws which I don't like about 
> > > most win32-style installers, and which loki_setup avoided. For instance 
> > > it's script based, uses an API of bash script functions, and I'm really 
> > > not fond of that stuff.
> > 
> > The script base is because for many apps (not games, which loki_setup is
> > mostly geared for) rather intricate installation procedures are
> > necessary.
> I hate to pick on this, but I think that's tosh.
> Most apps SHOULD be simple to install and uninstall. That goes double

SHOULD does mean ARE.  And a system that only works for most apps and
not all apps isn't a useful system.  Autopackage is intended for any and
all kinds of applications, including things that require scripts in
order to properly install.  Even simple apps can often require scripts
for things like registering new plugins with frameworks, shutting down
system services before install and restoring them after, and so on.

Autopackage developers are indeed advocates of intelligent software
development practices (which means, among other things, that
installation should be short sweet and simple), but they also aren't so
idealistic as to believe that's what the reality of the current
Linux/UNIX landscape is.

> for windows. Most linuxy apps can either go in their own canned dir
> [as loki_setup is primarily arrranged around], or be spread thinly
> around the system. They're still JUST A LIST OF FILES.

Only for the most simple and self-contained of applications.

> Anything involving complex configuration, etc, should be done at
> first-run time, or  as a post-install script [as loki_setup already
> supports]

User configuration, yes.  Many apps require integrating at installation
time.  One good example is registering user documentation with
Scrollkeeper or adding new plugins to GStreamer.  Another example is how
certain pieces of software *require* a particular installation
directory, dependent on the location of other software already on the
system.  The user shouldn't be presented with a path (the user most
likely don't know the right answer anyway), so a script has to determine
this, and conditionally place some or all files in other-than-default
locations.  These aren't things the games Loki Setup was concerned with
had to deal with, but since Autopackage is intended for more than a
handful of relatively uninteresting installation use cases, it offers
capabilities applications may require, including (of course) scripting.

Again, simply offering scripting doens't mean you have to use it.  There
are likely a good number of functions in the standard C library you
won't ever use, but does that mean you shouldn't use the standard C
library?  ;-)

> I'm actually with TTimo on this one. That whole script thing always
> feel crappy, requires a coding ability as well as a simple descriptor
> language to  anday what files are where. And you really shouldn't need
> complex installation procedures. If you do, It's my considered opinion
> your app is badly written.

Coding ability is not a pre-requisite, as I mentioned in a previous
mail.  A package/installer designed would abstract all that away for
most packagers.  Applications requiring the complexity will still have
it available.  We all want the most simplistic and most stream-lined
system possible for the standard case, but we can't just assume the
complex case is non-existent or always a design error on the part of the
developer, and we need to be able to support it.

> For eg, if part of your installation requirements is logic on
> whether-or-not to replace a certain file already on the system [win32
> .dlls, I'm specifically thinking of], then you need to re-think your
> installation strategy.

That is of course one of a vast array of possible situations.  I agree
in this case, but as mentioned above there are other situations
(especially on Linux/UNIX) where that is pure idealism and you simply
can't avoid it.

> Just my .02, based on my own experience of crappy software and crappy
> installers.

Heh.  Yes, unfortunately, most software is crappy.  If we all had
systems comprised of well designed software and users only ever wanted
to install well designed apps, we wouldn't be worrying about Loki Setup
2, because the problem would already have been solved.  ~,^

> Gary (-;
Sean Middleditch <elanthis at awesomeplay.com>
AwesomePlay Productions, Inc.

More information about the Lokisetup mailing list