1 |
dams@g.o wrote: |
2 |
> I like the document, thx for this. |
3 |
> For the different architecture, I can test it on ppc on a regular basis. |
4 |
|
5 |
This is good. The more people on different archs, the more initial |
6 |
testing, the more stability, the more happy users. |
7 |
|
8 |
> About server/desktop distinction, I think the default (suggested) packages |
9 |
> installed does matter. |
10 |
|
11 |
Right. It should be (in my opinion) manual package selection by default. |
12 |
This is what our (current) users seem to expect, myself included. |
13 |
Working primarily with servers, having to choose from groups of packages |
14 |
that, no doubt, will contain stuff I don't want in each one is |
15 |
problematic and time consuming. |
16 |
|
17 |
> But before this distinction, I'd like your input about the global direction of |
18 |
> the installer : |
19 |
> |
20 |
> - should it be minimalist : partitioning, network, install X if desktop |
21 |
> oriented, and reboot. At first boot, have configuration tools + software |
22 |
> manager (to install stuff) displayed. This is what I'd prefer, because there |
23 |
> is no duplication, and you could call the config step after install. |
24 |
|
25 |
Minimalist, partitioning, network - absolutely. As for X, I *guess* so |
26 |
but again I'm inclined to say give them manual package selection. Since |
27 |
dependencies will be autoresolved, the user doesn't have to jump through |
28 |
hoops - they just select X. It's the same as giving them a predefined |
29 |
set of packages in that with one click, they get X and everything |
30 |
required. Same for desktop environment and / or window manager. Again, |
31 |
this is all in the interest of a simplified and common environment for |
32 |
both server and desktop. |
33 |
|
34 |
As for rebooting and when, I think the long it can be delayed, the |
35 |
better as rebooting (to me) signifies nearing or the end of installation |
36 |
and makes me wait for something else. Of course, compiling makes me |
37 |
wait, but rebooting is more mentally indicative of being finished. |
38 |
|
39 |
As for configuration, we can use self destruct tools. Prior to reboot, |
40 |
place a configuration controller script in /etc/runlevels/default that |
41 |
leads the user through final config (for desktop only - remember that |
42 |
server has its unattended post flight config) and when finished, simply |
43 |
removes the link, leaving the control script itself, if desired. |
44 |
|
45 |
> - should it be complete : partitioning, network, different installation groups, |
46 |
> full config (net, users, security, server packages, printing, sound, ...) |
47 |
|
48 |
Of course. The goal is for the user to have to do as little manual post |
49 |
flight work but without bloating the pants off of the installer. |
50 |
|
51 |
> I think it's interesting to think about that now |
52 |
|
53 |
Yes. These are all design decisions and should be worked out prior to |
54 |
"the effort." |
55 |
|
56 |
Thanks for the comments. |
57 |
-- |
58 |
Eric Sammer |
59 |
Gentoo Linux |
60 |
http://www.gentoo.org |