Re: [gentoo-project] Question about a installer for Gentoo.

[Angelo Arrifano]

On 14-10-2010 16:19, Richard Freeman wrote:
> On 10/14/2010 09:05 AM, Angelo Arrifano wrote:
>> Since most of the install process is already automated by emerge. Most
>> of work left to the user is indeed configuration of the system
>> (make.conf, conf.d & friends).
>>
>> So I would instead focus on a CLI util to help quickly generate (up to
>> date) configuration files for make.conf and conf.d files. - that is what
>> takes most of the time..

Also, for simple config files like hwclock, a few in-line annotations
are enough to guide a (I called it CLI before but I was more turned into
ncurses) GUI application to help the user to quickly edit those configs.
The referred annotations would be written as comments in the config
files itself. The GUI app would then parse the annotations and present a
GUI interface based on those.

<-- Something like:
# %?DESC?%
# Set CLOCK to "UTC" if your Hardware Clock is set to UTC (also known as
# Greenwich Mean Time).  If that clock is set to the local time, then
# set CLOCK to "local".  Note that if you dual boot with Windows, then
# you should set it to "local".
# %?TYPE=LIST(["UTC", "local"])?%
clock="UTC"

# %?DESC?%
# If you want to set the Hardware Clock to the current System Time
# (software clock) during shutdown, then say "YES" here.
# You normally don't need to do this if you run a ntp daemon.
# %?TYPE=BOOL?%
clock_systohc="YES"

# %?DESC?%
# If you wish to pass any other arguments to hwclock during bootup,
# you may do so here. Alpha users may wish to use --arc or --srm here.
# %?TYPE=STR?%
clock_args=""
-->

This file continues to be human readable and can also be parsed by said
GUI app. The GUI will then present something like kernel's menuconfig.
Variable names as options with simple type checking, the variable values
as default values, and keywords like "?" to display the variable's
description. I'm not sure if this kind of annotations are being used
elsewhere to edit config files, I just came up with it due to their
usefulness in formal methods.

For more complicated examples like conf.d/net, I'm afraid separate XML
files would be required.

>
> I sort-of agree.  I think another goal should be to push all
> interactivity closer to the start of the process.

That sounds like a very good idea. I value the idea of being able to
configure FOO before or during FOO's emerge.
>
> For example, ideally you should be able to configure everything before
> running a single emerge.  That creates the problem that the
> configuration files are downloaded by emerge (How do you configure grub
> before you install it?  Ditto for the kernel?).
>
> In an ideal world, the user might spend some time configuring the box
> (perhaps before even booting it off of the CD with some kind of
> kickstart mechanism), then they'd start emerge or some script and it
> would install everything they need such that they just need to reboot.
>
> Right now you install something, then configure it, then install
> something else, then configure that.  That leads to lots of "wait 15
> minutes to several hours for build time" steps.

++
>
> If you could configure network, kernel, grub, etc, and then get a list
> of packages to emerge (like dhcpcd, gentoo-sources, grub, etc), then
> users could walk away and come back to a rebooted and running system.

Assuming the user didn't make any mistake in their config files ;)
>
> Rich
>

- Angelo