[lokisetup] setup v2 (was lokisetup for dummies)

[Sean Middleditch]

On Mon, 2004-01-05 at 13:24, Chunky Kibbles wrote:
> On Mon, Jan 05, 2004 at 12:15:59PM -0500, Sean Middleditch wrote:

> > Again, a lot of software needs various components placed in different
> > places depending on the system.  RPM and other packaging systems don't
> > do this because the packages are intended for a single version of a
> > single distro.  Commercial vendors don't want that, and even a good
> > number of Free Software developers would rather not subject their users
> > to the headache of distro/version dependent packages.
> 
> Specific examples?

Take desktop integrated packages for GNOME/KDE - they often need many
various files (things like Bonobo/DCOP server registration files) placed
in the specific install directories of the DE, which varies among
distros (some put in /usr, some in /usr/local, some in /opt/$DE, some
users even have them in $HOME).  

Plugins and such are another example, where the install location of the
host app is necessary.

When installing these files, you have to register them properly with the
package "database" in order to be able to uninstall them properly.  If
the whole app goes in /usr/local/$APP, uninstalling is as easy as a
quick rm -fr command.  When you have the base package and several
sub-components spread all over, you need something more intelligent than
providing an base path to tar for extraction.

I'm not saying Autopackage's solution of using bash is the best or only
way to do this, only that they needed a solution for this problem, and
that is the solution they chose.  Perhaps if you asked on the
autopackage-dev mailing list, the developers could provide more insight
as to their choice and future plans regarding the system.  Certainly
more than a mere observer and user like me could provide.  ;-)

> 
> > Another example is the install configuration support that applications
> > which are not user-oriented need.  For example, a game may have a "first
> > run" wizard/druid/app for configuring its settings.  A print system may
> > have a configuration program.  A browser plugin that is capable of
> > connecting to one of three different available helper programs, on the
> > other hand, may need some configuration at install time.
> 
> Hmm. Interesting, but that specific case is actually done, in the one
> example I'm familiar with, post-install. Codeweavers install all their
> stuff into {wherever}, and you can run the tool after installation
> that you tell where various browsers are installed, and it then
> installs and configures the plugins based on that. Plus, they even use
> setup :-)

That is also a complete PITA.  I, as a user, think that solution is
abhorrent.  There is absolutely no reason I should have to spend my time
setting things up, especially low-level things like selecting browsers
and their paths (these are things many users don't even *know* - if you
don't believe me, go read the GNOME/KDE mailing list archives and forums
and see the tons of users who don't even know what the name of their
browser is, much less where its installed) when the installation system
could've done it for me.

<mini-rant>On one end, there is the "simple and elegant" solution for
developers.  To be honest, that would be a tarball with a README.  On
the other hand, there is the simple and elegant solution for users.  A
system that's leaning too far towards the former won't be easy enough to
use, and to be frank, you might as well not bother making your software
if only uber-geeks can install it.  Every friend and family member I've
setup with Linux I've ended up installing Windows for, simply because
installing apps (including those based on loki_setup) was too
complicated for them.  (The Neverwinter Nights install is among the
worst, altho that isn't based on loki_setup.)  If it's not as easy as 1)
insert CD, 2) click install, 3) play, then there is a problem. 
Especially since, with a little effort on the part of the packager,
nothing is stopping it from being that easy.  That same effort is put
into most Windows software and there is no reason why it shouldn't be
put into Linux/UNIX software as well.</mini-rant>

> 
> I'm not trying to simply poo-poo all your points, here, I'm simply
> trying to work out what features it actually is that loki_setup
> doesn't have that you want.
> 
> Something akin to debconf is mostly blue-sky and would pretty much
> fail to make loki_setup smaller...

To be honest, I'm not really talking about problems with loki_setup, so
much as discussing possible reasons for integrating with Autopackage
versus developing two separate, incompatible packaging systems.  :)

One thing I'm basing most of this on is that the setup utility doesn't
*need* to be smaller, because it should be installed on the user's
system already.  Big commercial products shipped on CD can include a
copy of the installer engine, while downloaded projects can just require
that the install engine already be installed (just like much Linux
software requires RPM be installed, or that you have a compiler, or that
your have XFree86, or that you have working OpenGL, etc).  Autopackage
even has the ability to download and install the engine if you don't
have it already by using a small bootstrap stub in each .package file.

Of course, if there are a ton of separate specialized packaging systems
that aren't compatible with anything else, none of them are ever going
to be standard on systems.  Other advantages to having a pre-installed
installation engine have been discussed elsewhere in this thread.  (My
personal favorite being that pre-installed engines can take into account
changes or customizations that an engine included with the software
won't know about, which helps future proof the system, which is *very*
important especially on Linux systems, where the whole system changes
every couple years, unlike Windows where an installer that worked in
3.11 is likely going to work in Win2k3 as well.)

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