At 16:12 Uhr +0100 16.03.2005, Stefan Urbanek wrote:
Citát "M. Uli Kusterer" <[EMAIL PROTECTED]>:
<snip>
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.
No way to install GNUstep like that. "I do not want to reboot my computer to
have that thing."
Umm, I meant in the case where you have a full
GNUstep-based GNUstep. I probably should have
said "A GNUstep operating system", not just "a
GNUstep desktop". But yeah, I guess the more
common case until then will be people who want
the desktop only, to put on top of their Linux,
so the non-live approaches will have more
priority than I thought.
You mean a very simple, host environment native,
'GNUstep bootstrap/installer'?
Yes, that would be needed then. But it should
already look and behave steppish. I.e. it would
be an X11 app that works and behaves just like
Installer.app. That would provide a better user
experience, and people who only got Linux for
GNUstep would have GNUstep look-and-feel as
quickly as possible.
I would not go with the "GNUstep light" path as this can add more weight into
the downloaded package. Using native installation mechanisms has several
advantages:
- users are familiar with them (they do not jump into something unknown)
- already provides installation code - one has to provide only information
about
the installation (configuration scripts can be added)
On the other hand, there is a disadvantage. That is that each environment has
to
have its own bootstrap installer which is non-portable. However, if we can
manage to convert some custom GNUstep Environment installation instructions
(wizard steps?) to native installer
instructions, that can simplify creation of
installers.
That would be another option. Technically, even
just a shell script that performs the
installation would work. The important thing
would be that it'd be easy and consistent to use.
On platforms that already have a good interface
for their own packaging system, native packages
would probably work just fine, but the more of
the after-installation setup things we can
automate, the better.
And I'd like to avoid the experience I had with
Debian, where during system installation, I had
three different text-based UIs for installation,
and then got a fourth graphical metaphor when
launching X11.
Btw. how Java R.E. installers look like and work on different systems?
I'm not familiar with those ?
--
Cheers,
M. Uli Kusterer
------------------------------------------------------------
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de
