| 1 |
(warning: long text) |
| 2 |
Hi all, |
| 3 |
|
| 4 |
the recent discussion about an installer has been very polarized. Some |
| 5 |
people would like to see an easy-to-use installer, some would like |
| 6 |
scriptability, others prefer an automatic installer. There are even |
| 7 |
those that say that documentation and a bash shell are enough. |
| 8 |
|
| 9 |
This discussion happens about twice a year, and in the end not much |
| 10 |
changes. The documentation has become much better, there are small |
| 11 |
helpers (net-setup on the livecd, glis, ...), but no coordinated effort |
| 12 |
for a "nice" installer or a unanimous "there will be no installer". |
| 13 |
|
| 14 |
I know that developping a complete installation routine that is (almost |
| 15 |
;-) ) acceptable to most Gentooists is a lot of work, but since the |
| 16 |
issue keeps coming up every now and then there seems to be a genuine |
| 17 |
demand for it. |
| 18 |
|
| 19 |
>From what I've read, the installer should have the following attributes: |
| 20 |
|
| 21 |
* optional - this has been emphasized by many, and I agree. Choice and |
| 22 |
all that. |
| 23 |
|
| 24 |
* multiple output modules - Since there won't be a compromise between a |
| 25 |
fully graphical installer ("eyecandy") and a textmode installer |
| 26 |
(fallback when there is no graphics hardware) a user-selectable output |
| 27 |
is desirable. This will be a lot of work and not very rewarding since |
| 28 |
much functionality has to be duplicated. |
| 29 |
|
| 30 |
* scriptable - the installer should have the option of reading all |
| 31 |
configuration files from a location and run without interaction. |
| 32 |
|
| 33 |
* automation - most of hardware detection and package selection should |
| 34 |
have an automagic configuration mode that selects sensible default for |
| 35 |
users that don't want to read the fine manual :-) |
| 36 |
|
| 37 |
At the same time I'd like to see all the configuration utilities |
| 38 |
unified. There are obvious tools (emerge) and non-obvious |
| 39 |
(dispatch-conf, gcc-config). And often I think "having $tool would |
| 40 |
rock!" only to find it half an hour later. |
| 41 |
|
| 42 |
Also, there are many small tools that are not well documented |
| 43 |
(revdep-rebuild, ...). |
| 44 |
It would be really amazing to have a tool (call it "setup") that could |
| 45 |
detect what software was installed (maybe ebuilds could drop a "config" |
| 46 |
file into /etc/setup/ ?) so that administration could get a bit more |
| 47 |
focused. |
| 48 |
|
| 49 |
This tool could read an interface file like this: |
| 50 |
(option "Start blah?" [yes|no] yes: exec "blah --start" no: exec "blah |
| 51 |
--stop" default stop) |
| 52 |
|
| 53 |
(syntax and capabilities can be adapted as needed) |
| 54 |
|
| 55 |
So, on startup, "setup" reads all files in /etc/setup, creates menu |
| 56 |
entries on the fly, and there you have a nice configuration utility. |
| 57 |
Optional enhancments would be ncurses-setup, ksetup, gsetup ;-) |
| 58 |
Installation could be seen as a special case of configuration ... |
| 59 |
(Once you have a frontend / menu logic you "only" have to exchange the |
| 60 |
script backend) |
| 61 |
|
| 62 |
I think these tools would be very nice to most users, but I also see the |
| 63 |
amounts of work needed. I'd like to know if my ideas are halfway |
| 64 |
realistic and if Gentoo could benefit from this. Also, since this is a |
| 65 |
lot of work and maintenance, if there is enough support on the |
| 66 |
development side. |
| 67 |
|
| 68 |
Just my 2 cent (European), |
| 69 |
Patrick Lauer |
| 70 |
|
| 71 |
|
| 72 |
|
| 73 |
|
| 74 |
|
| 75 |
|
| 76 |
-- |
| 77 |
gentoo-dev@g.o mailing list |
Archives