1 |
Scott Koch <scootersmk@×××××××××.net> writes: |
2 |
|
3 |
>> [snip: no all or nothing installer] |
4 |
|
5 |
>> Also, with a good modular design we can add piece by piece what we think to be |
6 |
>> necessary, and in the other places the installer would just tell the user |
7 |
>> things out of the install howto or not even that. That way we avoid overdoing |
8 |
>> it - writing things our audience doesn't really need. |
9 |
|
10 |
A possible way to support this would be to separate the |
11 |
single-user/``desktop user'' installer into a number of executables |
12 |
which automate or help the user perform a single step. This executables |
13 |
could possibly be simple front-ends for libraries, some of which are |
14 |
also used in other installer configurations, such as the enterprise |
15 |
environment installer. |
16 |
|
17 |
Then the user can simply run the program to complete a given step, and |
18 |
these `helper' programs can be mentioned in the installation |
19 |
documentation, as is ufed and mirrorselect (IIRC). |
20 |
|
21 |
The primary issue that I see with this approach is that it might be |
22 |
desirable for the user, even in a non-scripted (i.e. non-enterprise |
23 |
environment) install, to be able to enter all information at the |
24 |
beginning of the process, and then leave the machine unattended during |
25 |
the remainder of the installation. One key issue to deal with will be |
26 |
avoiding problems with config file updating, since there is no easy way |
27 |
to automate etc-update, but doing so is critical to automated |
28 |
installation, and more importantly, maintenance of a large number of |
29 |
Gentoo machines. |
30 |
|
31 |
> This is the style of installer that would be the best match for Gentoo(quoted |
32 |
> above). I think it would be a big mistake to stray far from the current |
33 |
> process. As far as I am concerned the console/ split-screen installer is a |
34 |
> must. |
35 |
|
36 |
This is supported by screen. (The installation documentation could |
37 |
recommend the use of screen) |
38 |
|
39 |
> Our main concern should be getting the user comfortable with the current |
40 |
> install process, instead of changing the installer to better fit the user. The |
41 |
> new installer needs consist of various add-ons (to the current process) to make |
42 |
> the user more comfortable ("Holding their hand and walking them through") with |
43 |
> the install process. |
44 |
|
45 |
If this is the only purpose for the single-user (``desktop user'') |
46 |
installer (as opposed to enterprise-environment deployment), it seems |
47 |
that the documentation serves this purpose already in fact. A few more |
48 |
tools, such as ufed, could be helpful, but I have a hard time thinking |
49 |
of many which are actually needed. (A network configuration tool could |
50 |
be useful, but then again, it is quite easy to edit /etc/conf.d/net with |
51 |
a text editor, and copying /etc/init.d/net.eth0, even for a novice user, |
52 |
and clearly editing text files as simple as /etc/conf.d/net will be a |
53 |
necessary task for any GNU/Linux system administrator, or even a |
54 |
non-system-administrator user.) |
55 |
|
56 |
> [snip: must not hide anything] |
57 |
|
58 |
> [snip: installer deciding factor] |
59 |
|
60 |
-- |
61 |
Jeremy Maitin-Shepard |