1 |
Alright, we are narrowing in. I think starting with a CLI installer makes |
2 |
sense because it will allow us to work on the true installation issues |
3 |
rather than getting bogged down in gui code. Lets use python. That will |
4 |
let us to use both Cursing Cow and Anaconda as great resources for just |
5 |
about every step of the installation. Once we feel like everything runs |
6 |
smoothly on a variety of boxes then we can work on putting a gui on top. |
7 |
(I think wxPython is the best solution. Its clean, quick and extensive. |
8 |
We could even use a gui builder to quickly experiment with a variety of |
9 |
interface options.) Anyway, that is for later. |
10 |
Building the installer as a set of install/configuration modules |
11 |
is a great idea. Lets start with defining those modules, and then we can |
12 |
work on common code etc. before digging in. |
13 |
I propose that we break this whole idea into 3 main sections. |
14 |
(Note: This has nothing to do with the stage1,2,3 tarballs.) |
15 |
|
16 |
First, we need the basic gentoo installation: |
17 |
|
18 |
- partitioning and file systems (RAID support? SCSI cards?) |
19 |
- nic detection and module loading (Pretty much complete?) |
20 |
- dns, routing, firewall stuff |
21 |
- date & time |
22 |
- keyboard, mouse, language |
23 |
- cpu detection and compiler flags |
24 |
- mounting partitions and getting stage tarball setup |
25 |
- password & hostname |
26 |
- fstab |
27 |
- bootloader setup (interfaces to lilo and/or grub) |
28 |
|
29 |
Once the basic system is installed we move into part 2, |
30 |
initial Portage system installation and configuration: |
31 |
|
32 |
- Portage tree sync |
33 |
- Setting use flags |
34 |
- Kernel configuration |
35 |
- build |
36 |
|
37 |
Now we have a basic system installed. We can reboot into our new |
38 |
kernel and start the final, most difficult, stage of installation: package |
39 |
selection. Rather than just copying everyone else and making large lists, |
40 |
lets try to make this more intuitive. Maybe we could have a few bundles |
41 |
that people can select to get rolling quickly, but full control should |
42 |
still given to the user. Personally, I would rather just get a |
43 |
working gnome/kde installation and then use a gui selection tool rather |
44 |
than some clunky ncurses thing. Maybe we could have a very lightweight |
45 |
CLI manager that lets you select gnome, kde or just cli. If they use |
46 |
gnome or kde then we give them a slick gui manager once X starts up. If |
47 |
they use cli then they are probably setting up a server and they can deal |
48 |
with using emerge as is. |
49 |
After looking through a bunch of code I agree we should really try |
50 |
to use a lot of the existing stuff to get things started. The LiveCD |
51 |
pretty much does all the very initial stuff. After that we can use the |
52 |
cursing cow work to put together the install stage1 and part of stage2. |
53 |
For stage 3, I think we should build a python gui (wxPython?) that doesn't |
54 |
use kde or gnome specifically. This is where a lot of the experimentation |
55 |
will need to go. |
56 |
|
57 |
Whooh... What do you say? I'll be graduating in a month so I won't be |
58 |
able to work a whole lot until the summer begins, but I think we should |
59 |
try to refine this idea/design a lot before diving in and hacking out |
60 |
something that just works. |
61 |
|
62 |
Peace! |
63 |
Jeff |
64 |
|
65 |
|
66 |
On Sun, 13 Apr 2003, Alain Penders wrote: |
67 |
|
68 |
> The main installer that was being worked on is Cursing Cow. Both developers |
69 |
> that were working on it recently left Gentoo, however. |
70 |
> |
71 |
> If someone wanted to continue it's development, we probably can get the |
72 |
> information needed from them. From what I know, it's in pretty good |
73 |
> condition... part of it needed to be rewritten, but nothing major. |
74 |
> |
75 |
> There's at least one (I think two) other installers in CVS, but I have no idea |
76 |
> on their status or where they were left at. |
77 |
> |
78 |
> |
79 |
> Building a good installer goes beyond installing Gentoo. For example, if the |
80 |
> installer has a module to configure networking, that module should be written |
81 |
> so that it works in the installer, but also in an after-install system |
82 |
> configuration tool. Installers also need to be able to handle updates or |
83 |
> "corrective installs", which means integration with configuration file |
84 |
> management. |
85 |
> |
86 |
> Alain |
87 |
> |
88 |
> |
89 |
> |
90 |
> On Fri, Apr 11, 2003 at 05:04:10PM -0600, Jeff Rose wrote: |
91 |
> > Hello, |
92 |
> > I'm pretty new to gentoo, but I am an instant convert. Just a |
93 |
> > few months of emerge bliss and now I'm an avid supporter. Anyway, I'm |
94 |
> > thinking about starting a summer project and I'm pondering the idea of a |
95 |
> > gui installer. I've been looking around a bit and it doesn't look like |
96 |
> > anyone is working on one. Is that true? If there isn't already a project |
97 |
> > then I think I'll give it a whirl. I know, I know, gentoo is so great |
98 |
> > because it allows you to customize and tweak the hell out of everything. |
99 |
> > That is completely true. So, an installer would have to allow just as |
100 |
> > much but it could take care of the mundane details for those who aren't |
101 |
> > interested or knowledgable enough. |
102 |
> > I haven't been around to see what people discuss in terms of the |
103 |
> > installer so I'm sorry if this is all stuff that you have gone over |
104 |
> > hundreds of times. Even more minimal than a gui installer, have you |
105 |
> > thought about adding more scripts to do the standard directory setup, |
106 |
> > download, chroot... type of stuff? |
107 |
> > What do you think? |
108 |
> > |
109 |
> > -Jeff |
110 |
> > |
111 |
> > |
112 |
> > -- |
113 |
> > gentoo-dev@g.o mailing list |
114 |
> > |
115 |
> |
116 |
> -- |
117 |
> gentoo-dev@g.o mailing list |
118 |
> |
119 |
|
120 |
|
121 |
-- |
122 |
gentoo-dev@g.o mailing list |