1 |
I think we should take a look at RedHat's installer to see what goes on |
2 |
underneath. For what I have used, it's hardware detection worked |
3 |
perfectly...i believe it's kudzu that drives it. |
4 |
|
5 |
In my opinion, the installer should just do a stage install, and |
6 |
everything that the install doc describes...then on reboot maybe dump to |
7 |
X or a ncurses interface giving the user options on what to do next. I |
8 |
like how Debian does it, basic install, then allow dpkg to be configured. |
9 |
|
10 |
Opinions? |
11 |
|
12 |
Jeff Rose wrote: |
13 |
|
14 |
>Well, I'm glad to see that people are interested. After doing some |
15 |
>initial research I have some thoughts. First, we should decide on whether |
16 |
>we want to have a terminal or X based installer. Does anyone know how |
17 |
>well the generic vesa driver works for X? I personally have battled with |
18 |
>X so many times that I'm not sure I think its worth it for an installer. |
19 |
>(Although we could just use the RedHat stuff for autodetection etc. if we |
20 |
>want to go that direction.) Besides X we could use ncurses dialog |
21 |
>widgets or another terminal gui package. I was thinking it would be cool |
22 |
>to use somethine lighter than X like svgalib. I have no experience with |
23 |
>it and don't know how cross platform (or cross video card) it is, but it |
24 |
>could be a cool solution if a decent widget set is put on top of it. I'm |
25 |
>not sure if this would lead to more or less work than using X. |
26 |
> As for choosing stages, that should be a decision made by the user |
27 |
>at install time. We can very briefly explain how the system works and let |
28 |
>them do what they please. For the complete novice we can basically have |
29 |
>the "do everything for me" button. For the supreme hacker we can let them |
30 |
>have it all while still taking care of mundane details. (For example, |
31 |
>they could choose what file systems they want to use on what partitions, |
32 |
>but that would just be a selection dialog rather than having to type the |
33 |
>commands etc...) It might be nice if the installer can be exited at any |
34 |
>point so people have the ability to get things rolling quickly but then |
35 |
>tweak things out to their hearts content once its where they want it. |
36 |
> One of the major pains in the redhat like installers deals with |
37 |
>package selection. I think it is ridiculous to give people a list of a |
38 |
>thousand packages and tell them to pick. Especially since the package |
39 |
>documentation is horrible. Most people probably wouldn't know that its |
40 |
>important for them to have the e2fsprogs installed, for example. So, this |
41 |
>is the portion of the installer where I see the most room for innovation. |
42 |
>Especially since gentoo has such a unique package system, we should really |
43 |
>try to enable the user as much as possible, rather than just hucking a |
44 |
>bunch of packages into the mix. I'm still working on ideas, but we should |
45 |
>experiment with all kinds of stuff to get this stage really smoothed out. |
46 |
> This idea of processor detection makes me think that a whole lot |
47 |
>of detection could go on if we wanted it to. The thing is detection is |
48 |
>useless unless you can act on what you have detected. Changing some CPU |
49 |
>related compiler flags is one thing, but what about detecting network, |
50 |
>sound, video, raid, scsi, firewire, printers etc. This could all get very |
51 |
>tricky real fast. What about using RedHats kudzu? |
52 |
> |
53 |
>Peace, |
54 |
>Jeff |
55 |
> |
56 |
> |
57 |
|
58 |
|
59 |
-- |
60 |
gentoo-dev@g.o mailing list |