On 2005-03-16 14:08:06 +0000 M. Uli Kusterer <[EMAIL PROTECTED]> wrote:
> 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. > oh, absolutly, the feedback has been taken into account, and I'll write to discuss about my general conclusions. I'm taking into consideration the proposed suggestions to guarantee that I don't make a design assumption that latter on proves inflexible to them. I was just talking about setting milestones. > 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. > Well, it will be able to install them trough bundles, but an entire system is a different beast than individual packages... I think it would be better to leave the OS installtion to regular CLI tools, and only use Installer to set GNUstep, i.e. not glibc and base-utils... > 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. Well, the last time I thought about this (using Installer not only to install add-ons, but GNUstep proper) it came to mind the idea of having a statically compiled Installer.app (that would be much bigger in size) that would be used to install GNUstep, and would also install the "regular" Installer.app, removing itself in the end. I don't know if this is possible though, but it would be much better than to write a C wrapper for it... I think it's important to use GNUstep from the begining. I'm, as always, open to suggestions on this. Best regards, fsmunoz
