I think we should take a look at RedHat's installer to see what goes on 
underneath.  For what I have used, it's hardware detection worked 
perfectly...i believe it's kudzu that drives it.

In my opinion, the installer should just do a stage install, and 
everything that the install doc describes...then on reboot maybe dump to 
X or a ncurses interface giving the user options on what to do next.  I 
like how Debian does it, basic install, then allow dpkg to be configured.

Opinions?

Jeff Rose wrote:

>Well, I'm glad to see that people are interested.  After doing some
>initial research I have some thoughts.  First, we should decide on whether
>we want to have a terminal or X based installer.  Does anyone know how
>well the generic vesa driver works for X?  I personally have battled with
>X so many times that I'm not sure I think its worth it for an installer.
>(Although we could just use the RedHat stuff for autodetection etc. if we
>want to go that direction.)  Besides X we could use ncurses dialog
>widgets or another terminal gui package.  I was thinking it would be cool
>to use somethine lighter than X like svgalib.  I have no experience with
>it and don't know how cross platform (or cross video card) it is, but it
>could be a cool solution if a decent widget set is put on top of it.  I'm
>not sure if this would lead to more or less work than using X.
>	As for choosing stages, that should be a decision made by the user
>at install time.  We can very briefly explain how the system works and let
>them do what they please.  For the complete novice we can basically have
>the "do everything for me" button.  For the supreme hacker we can let them
>have it all while still taking care of mundane details.  (For example,
>they could choose what file systems they want to use on what partitions,
>but that would just be a selection dialog rather than having to type the
>commands etc...)  It might be nice if the installer can be exited at any
>point so people have the ability to get things rolling quickly but then
>tweak things out to their hearts content once its where they want it.
>	One of the major pains in the redhat like installers deals with
>package selection.  I think it is ridiculous to give people a list of a
>thousand packages and tell them to pick.  Especially since the package
>documentation is horrible.  Most people probably wouldn't know that its
>important for them to have the e2fsprogs installed, for example.  So, this
>is the portion of the installer where I see the most room for innovation.
>Especially since gentoo has such a unique package system, we should really
>try to enable the user as much as possible, rather than just hucking a
>bunch of packages into the mix.  I'm still working on ideas, but we should
>experiment with all kinds of stuff to get this stage really smoothed out.
>	This idea of processor detection makes me think that a whole lot
>of detection could go on if we wanted it to.  The thing is detection is
>useless unless you can act on what you have detected.  Changing some CPU
>related compiler flags is one thing, but what about detecting network,
>sound, video, raid, scsi, firewire, printers etc.  This could all get very
>tricky real fast.  What about using RedHats kudzu?
>
>Peace,
>Jeff
>  
>


--
gentoo-dev@g.o mailing list