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