[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Corel Setup Design Proposal

Enrique Zanardi wrote:
> I've got some more comments to your proposal:

> a) Your proposal assumes the user will do a CD-ROM based installation.
> But we support floppy (the horror, the horror) and network based
> installations as well. For network based installations, the rescue image
> would have to mount a remote medium (probably by NFS) to start X from it.
> That means configuring the network before using X. Have you thought
> about that for your design?
For now we onlywould support an X based install from CD-ROM
. All others would revert to console<curses> mode
> b) 2.2.x with all SCSI drivers compiled in is a huge beast. Are you going
> to compile them as modules? If so, where are they going to be loaded
> from? When? (You may need them while detecting the cdrom and hard drive
> devices).
Yes we would have to build a modularized kernel much like the Red Hat system.
> c) You call it a "rescue" image. Does that mean the user can boot from it,
> open a shell and use a bunch of command-line tools to mount a partition,
> edit some files, extract a tgz file, and all those things that one can do
> with just a rescue floppy?
I'd like to keep the rescue image as is as far as functionality
> > We are also looking at a a replacement for dselect(it would still be
> > installed),
> > as the primary means of  choosing custom packages, again this would be
> > based from the setup UI calling the needed functions from within the
> > setup API.

> What about looking at apt front-ends? gnome-apt is currently a very
> interesting candidate.
 One of our developers is working on apt ,  I think that a joint effort here is really important
to get the replacement right. Gnome-apt may be a great place to start from.

Also please let me clarify that the setup API is separate from the setup UI.
1.The setup API is a shared library that would reside in the root.bin image on the rescue floppy image.
2.The setup UI (be it GTK and/or QT based ) would reside on the CD-ROM. I have also
  mentioned the curses setup UI, it would , unlike the other GUI based setup UI's, 
  reside in the root.bin image of the rescue floppy image.
3. On the issue of QT. please note that I don't believe that Debian should use this.
  I would rather see your UI based around something like GTK. When I mention QT it is only
  to do with Corel's version of the setup UI , which to point out again, is not built into the setup API .
4.Frame buffer. Again if it can be demonstrated that it works under the requirements that I have been
  given(a nice GUI based front end -> GTK/QT2 widgets) then yes we'll use it.
5. I really think a well planned gradual phase in of this concept is needed on many levels.
       A.Debian supports many other platforms and would need time to convert them and do any modifications
         to make this work.
       B.We could use an X based install initially and then move to frame buffer once it's ready.
       C.A console based install must be included in all situations as a choice and in some cases


Reply to: