Gentoo Archives: gentoo-project

From: Angelo Arrifano <miknix@g.o>
To: gentoo-project@l.g.o
Subject: Re: [gentoo-project] Question about a installer for Gentoo.
Date: Thu, 14 Oct 2010 16:02:59
In Reply to: Re: [gentoo-project] Question about a installer for Gentoo. by Richard Freeman
1 On 14-10-2010 16:19, Richard Freeman wrote:
2 > On 10/14/2010 09:05 AM, Angelo Arrifano wrote:
3 >> Since most of the install process is already automated by emerge. Most
4 >> of work left to the user is indeed configuration of the system
5 >> (make.conf, conf.d & friends).
6 >>
7 >> So I would instead focus on a CLI util to help quickly generate (up to
8 >> date) configuration files for make.conf and conf.d files. - that is what
9 >> takes most of the time..
11 Also, for simple config files like hwclock, a few in-line annotations
12 are enough to guide a (I called it CLI before but I was more turned into
13 ncurses) GUI application to help the user to quickly edit those configs.
14 The referred annotations would be written as comments in the config
15 files itself. The GUI app would then parse the annotations and present a
16 GUI interface based on those.
18 <-- Something like:
19 # %?DESC?%
20 # Set CLOCK to "UTC" if your Hardware Clock is set to UTC (also known as
21 # Greenwich Mean Time). If that clock is set to the local time, then
22 # set CLOCK to "local". Note that if you dual boot with Windows, then
23 # you should set it to "local".
24 # %?TYPE=LIST(["UTC", "local"])?%
25 clock="UTC"
27 # %?DESC?%
28 # If you want to set the Hardware Clock to the current System Time
29 # (software clock) during shutdown, then say "YES" here.
30 # You normally don't need to do this if you run a ntp daemon.
31 # %?TYPE=BOOL?%
32 clock_systohc="YES"
34 # %?DESC?%
35 # If you wish to pass any other arguments to hwclock during bootup,
36 # you may do so here. Alpha users may wish to use --arc or --srm here.
37 # %?TYPE=STR?%
38 clock_args=""
39 -->
41 This file continues to be human readable and can also be parsed by said
42 GUI app. The GUI will then present something like kernel's menuconfig.
43 Variable names as options with simple type checking, the variable values
44 as default values, and keywords like "?" to display the variable's
45 description. I'm not sure if this kind of annotations are being used
46 elsewhere to edit config files, I just came up with it due to their
47 usefulness in formal methods.
49 For more complicated examples like conf.d/net, I'm afraid separate XML
50 files would be required.
52 >
53 > I sort-of agree. I think another goal should be to push all
54 > interactivity closer to the start of the process.
56 That sounds like a very good idea. I value the idea of being able to
57 configure FOO before or during FOO's emerge.
58 >
59 > For example, ideally you should be able to configure everything before
60 > running a single emerge. That creates the problem that the
61 > configuration files are downloaded by emerge (How do you configure grub
62 > before you install it? Ditto for the kernel?).
63 >
64 > In an ideal world, the user might spend some time configuring the box
65 > (perhaps before even booting it off of the CD with some kind of
66 > kickstart mechanism), then they'd start emerge or some script and it
67 > would install everything they need such that they just need to reboot.
68 >
69 > Right now you install something, then configure it, then install
70 > something else, then configure that. That leads to lots of "wait 15
71 > minutes to several hours for build time" steps.
73 ++
74 >
75 > If you could configure network, kernel, grub, etc, and then get a list
76 > of packages to emerge (like dhcpcd, gentoo-sources, grub, etc), then
77 > users could walk away and come back to a rebooted and running system.
79 Assuming the user didn't make any mistake in their config files ;)
80 >
81 > Rich
82 >
84 - Angelo