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.. |
10 |
|
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. |
17 |
|
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" |
26 |
|
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" |
33 |
|
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 |
--> |
40 |
|
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. |
48 |
|
49 |
For more complicated examples like conf.d/net, I'm afraid separate XML |
50 |
files would be required. |
51 |
|
52 |
> |
53 |
> I sort-of agree. I think another goal should be to push all |
54 |
> interactivity closer to the start of the process. |
55 |
|
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. |
72 |
|
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. |
78 |
|
79 |
Assuming the user didn't make any mistake in their config files ;) |
80 |
> |
81 |
> Rich |
82 |
> |
83 |
|
84 |
- Angelo |