| 1 |
This is what I'd call a checkpoint, some kind of summary of what I've |
| 2 |
understood of your ideas: |
| 3 |
|
| 4 |
For now, we are focusing of what we want in the installer, and also the general |
| 5 |
technical structure of it. The installer turns out to be usefull for beginners, |
| 6 |
advanced users, as well as the one who want to do automated.scripted install. |
| 7 |
|
| 8 |
The idea is to have a GUI + console + help in one single screen. console is |
| 9 |
useable to interact with the installation. The GUI is there to have easy |
| 10 |
access/representation of the install. |
| 11 |
|
| 12 |
We could try to build a scenario of the installer steps, and try to design the |
| 13 |
general installer screen. |
| 14 |
|
| 15 |
But I have one major interrogation : in the discussion, it's not clear where |
| 16 |
the installer stops, and where the config starts. We agree that the |
| 17 |
configuration process has to use the config tools, to avoid redundance. Now, |
| 18 |
should the install do minimal install (network + partitioning + installing base |
| 19 |
system - no package choice), then reboot or chroot in the new environment, then |
| 20 |
start various config tools, among them a portage frontend, user conf, sound, |
| 21 |
printing, X, language/i18n, ... ? Or do you want these steps to be in the |
| 22 |
installer GUI? (in the GUI/console concept, you could emerge stuff and |
| 23 |
configure everything by hand in the console, no need to reboot/chroot) |
| 24 |
|
| 25 |
|
| 26 |
-- |
| 27 |
dams |
| 28 |
|
| 29 |
-- |
| 30 |
gentoo-desktop-research@g.o mailing list |
Archives