Gentoo Archives: gentoo-desktop-research

From: Jeremy Maitin-Shepard <jbms@g.o>
To: gentoo-desktop-research@l.g.o
Subject: Re: [gentoo-desktop-research] Gentoo installer project
Date: Tue, 27 Jan 2004 06:05:37
Message-Id: 87ad49gc0b.fsf@jbms.ath.cx
In Reply to: Re: [gentoo-desktop-research] Gentoo installer project by Scott Koch
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