| 1 |
On 10/14/2010 09:05 AM, Angelo Arrifano wrote: |
| 2 |
> Since most of the install process is already automated by emerge. Most |
| 3 |
> of work left to the user is indeed configuration of the system |
| 4 |
> (make.conf, conf.d & friends). |
| 5 |
> |
| 6 |
> So I would instead focus on a CLI util to help quickly generate (up to |
| 7 |
> date) configuration files for make.conf and conf.d files. - that is what |
| 8 |
> takes most of the time.. |
| 9 |
|
| 10 |
I sort-of agree. I think another goal should be to push all |
| 11 |
interactivity closer to the start of the process. |
| 12 |
|
| 13 |
For example, ideally you should be able to configure everything before |
| 14 |
running a single emerge. That creates the problem that the |
| 15 |
configuration files are downloaded by emerge (How do you configure grub |
| 16 |
before you install it? Ditto for the kernel?). |
| 17 |
|
| 18 |
In an ideal world, the user might spend some time configuring the box |
| 19 |
(perhaps before even booting it off of the CD with some kind of |
| 20 |
kickstart mechanism), then they'd start emerge or some script and it |
| 21 |
would install everything they need such that they just need to reboot. |
| 22 |
|
| 23 |
Right now you install something, then configure it, then install |
| 24 |
something else, then configure that. That leads to lots of "wait 15 |
| 25 |
minutes to several hours for build time" steps. |
| 26 |
|
| 27 |
If you could configure network, kernel, grub, etc, and then get a list |
| 28 |
of packages to emerge (like dhcpcd, gentoo-sources, grub, etc), then |
| 29 |
users could walk away and come back to a rebooted and running system. |
| 30 |
|
| 31 |
Rich |
Archives