| 1 |
Bart Verwilst wrote: |
| 2 |
> We're working on a graphical installer... |
| 3 |
> I'm planning to make it easier to install than Windows :) |
| 4 |
> Ofcourse this will be optional, and the current install will always be |
| 5 |
> available, and that's a garantee! :o) |
| 6 |
> |
| 7 |
> PS: This is a calling to everybody interessed, if you have ideas, drawings |
| 8 |
> from the layout, you're a talented graphics dude, or something, don't |
| 9 |
> hesitate to email me directly, we can use some help on this one :) |
| 10 |
|
| 11 |
What I like from the current handcrafted installation is that |
| 12 |
you see what is going on and you see that the installation is not a |
| 13 |
magical expert only thing, but just the matter of copying the files |
| 14 |
on a mounted filesystem. I like to install gentoo on machines running |
| 15 |
another distro or another gentoo disk because I can still use the |
| 16 |
machine and I have a more confortable environment where partitioning the |
| 17 |
disk etc. |
| 18 |
I think that there are some tasks which could be useful even for |
| 19 |
"experts": |
| 20 |
|
| 21 |
1) aided partitioning. I thought of having a file describing the |
| 22 |
partition structure (proplist, xml, whatever is easy to write and |
| 23 |
process with a (python?) script) fstypes and mount points. |
| 24 |
Then a script would take this file and make the partitions, create |
| 25 |
the filesystems, and output a fstab, to be copied in the newly created etc. |
| 26 |
I like to think of it as a text file, but it would be nice if |
| 27 |
the optional graphical installation could share the same format for |
| 28 |
storing user configuration, before doing the job, so that users |
| 29 |
can decide which parts of the graphical installation are useful (or just |
| 30 |
doing all auto if he wishes). |
| 31 |
I wanting to help writing this one, if you need help. |
| 32 |
|
| 33 |
2) device probing. I think it should be good if the graphical install |
| 34 |
(better than windows :-) would well divided from the logic that does |
| 35 |
device autodetection, so that users which doesn't want gfx install can |
| 36 |
also benefit from its detections. For example, once I needed to |
| 37 |
configure a asus ISDN card but I didn't know that asus was only the name |
| 38 |
on the box, and the cards was totaly incompatible with asus driver. |
| 39 |
Mandrake probed the device and configured correctly (or at least told |
| 40 |
me the chipset) (btw. lspci -> unknown). |
| 41 |
|
| 42 |
3) a use flag browser. It was confusing for me at first, and still it |
| 43 |
is, to see many use flags in /etc/make.globals and having to see what is |
| 44 |
in and what I should add, and what is available. I'd like to have a use |
| 45 |
flag list and some simple way of activating/deactivating which will |
| 46 |
output /etc/make.conf. |
| 47 |
|
| 48 |
I would find these things useful to save time and typing, retaining all |
| 49 |
the power of gentoo installation. |
| 50 |
|
| 51 |
I'd like that any work done in the graphical install could be reused |
| 52 |
separately to provide a custom installation method, if wanted. |
| 53 |
I mean, someone could build on top of it a complete graphical install, |
| 54 |
someone could only use a minimal ncurses based filesystem configuration |
| 55 |
tool... but without duplicating code. |
| 56 |
|
| 57 |
What do you think? |
| 58 |
|
| 59 |
If, eventually, the "config" files where expressed in xml, what is |
| 60 |
the littles packet for xml handling that wound fit in the installation |
| 61 |
environment. I heard that tinyqt will be used for portage2, and it has |
| 62 |
a xml parser, but it would be nice to write it in a scripting language |
| 63 |
(python?). I'm not a python guru. I wrote some little xml handling |
| 64 |
script but I don't know which parser is better to use. |
| 65 |
Any ideas ? |
| 66 |
|
| 67 |
Marko Mikulicic |
Archives