At 2:07 Uhr +0100 16.03.2005, Frederico Muñoz wrote:
My concern, and I'm sure you understood it, is
that while targeting advanced features and
experimental solutions the code stays always 10%
far from being finished. I prefer knowing that
it works for a well-defined and already used
paradigm that is immediatly usable and from
there, with the added confidence given by
something that works, adjust the code structure
to allow alternative methods, especialy since it
wil be easier to create new methods for them if
the existing ones are known to work.
The idea of starting at a regular installer and
moving onward from there sounds sensible to me.
The main point of the discussion on
GNUstep-discuss was to make sure future uses are
taken into account when designing the simple
installer. Otherwise it's too easy to take a
shortcut during design somewhere and suddenly
find out that this will cause problems when
implementing another feature.
Another thing to take into consideration is
consistency among installers. I.e. eventually, a
GNUstep desktop will need to be able to install
itself. Since Installer.app depends on GNUstep,
you'd need a Live CD to run the installer from,
and the installer would have to be flexible
enough to install an entire Linux (maybe through
a .deb or .rpm) onto another drive, without write
access to the disk, etc.
Without a Live-CD, we'd need an installer that
works completely without a GNUstep installation,
or which can work with some sort of
"GNUstep-Light" compiled into it (like
WindowMaker's setup app, which looks steppish,
but isn't dependent on GNUstep). I don't think
Installer.app should be implemented like this,
but if you find that some parts could easily be
implemented as a plain C installer library, that
would help the person who eventually has to code
the non-live installer.
--
Cheers,
M. Uli Kusterer
------------------------------------------------------------
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de
