| 1 |
At risk of being extremely repetitive, it seems to be worth repeating. |
| 2 |
|
| 3 |
Andrew Gaffney wrote: |
| 4 |
> I've got a few questions about the proposed new installer: |
| 5 |
> |
| 6 |
> 1. I've heard that the core installer will be written in Python. Is this |
| 7 |
> true? |
| 8 |
|
| 9 |
Docs. |
| 10 |
|
| 11 |
> 2. Whether Python or not, will real-time frontends have to be written |
| 12 |
> the same language as the core installer, or will it be controlled |
| 13 |
> through a pipe or similar method? |
| 14 |
|
| 15 |
I'm not entirely sure what you mean by "real time" but the physical |
| 16 |
commands will be shelled out where required. If you're asking if we're |
| 17 |
going to reimplement fdisk in pure python, the answer is a certain "no." ;) |
| 18 |
|
| 19 |
> 3. Will the core installer have plugin capabilities (e.g. user-created |
| 20 |
> configuration/installation steps), either scripted (bash) or coded |
| 21 |
> (Python or whatever)? |
| 22 |
|
| 23 |
It depends on what you want to do. You can create arch templates (see |
| 24 |
the docs re: arch templates) that define the steps to perform and the |
| 25 |
actions that will be taken. Custom steps (see the docs re: steps) can be |
| 26 |
added increasing the front end (see the docs re: front end) options and |
| 27 |
what the user may do. Arch templates basically implement the control |
| 28 |
portion of the back end (see docs re: back end) and handle the flow control. |
| 29 |
|
| 30 |
In short, docs. :) |
| 31 |
|
| 32 |
> 4. Which existing installer will the new code be based from or will this |
| 33 |
> be done completely from scratch possibly using existing concepts? |
| 34 |
|
| 35 |
Existing ideas will be taken and reused but all code will be a |
| 36 |
reimplementation to develop a generic platform. We'll be taking the best |
| 37 |
of each and running with it. Again, docs. |
| 38 |
|
| 39 |
> 5. Are there any plans to include X along with Qt, GTK, Tcl/Tk, etc. on |
| 40 |
> the LiveCD to allow for the creation of GUI installer frontends? |
| 41 |
|
| 42 |
There was talk of potentially creating a custom live cd with things that |
| 43 |
the installer can use / wants. Nothing was decided, but with catalyst, |
| 44 |
it becomes trivial (in comparison) so I imagine it will be decided later. |
| 45 |
|
| 46 |
A simpler answer is the main live cd will almost never contain a full X |
| 47 |
environment. Love it or hate it - people will never agree and it's |
| 48 |
outside the scope of the installer project to try and force such issues |
| 49 |
either way. |
| 50 |
|
| 51 |
> 6. What is already done? What needs to be done? What is still up in the |
| 52 |
> air? |
| 53 |
|
| 54 |
Docs, docs, and docs. |
| 55 |
|
| 56 |
> 7. How can I help? |
| 57 |
|
| 58 |
Writing docs. Writing code. Offering ideas. Testing. Testing. Testing. |
| 59 |
|
| 60 |
> I don't know Python, but I have pretty decent bash - |
| 61 |
> only since working on GLIS frontend ;) - and Perl skills. I don't know |
| 62 |
> any Python, but I can always learn. |
| 63 |
|
| 64 |
While writing code is not to be discounted, there are many ways to help. |
| 65 |
|
| 66 |
> 8. Anything else important that I might have missed? |
| 67 |
|
| 68 |
The docs. :) |
| 69 |
|
| 70 |
I'm sorry about busting your chops with regard to the docs. We have |
| 71 |
spent a lot of time putting them together to answer these kinds of |
| 72 |
questions (and others) and are trying to get people to look at them (and |
| 73 |
hopefully read them without glazing over). Of course, I jest for the |
| 74 |
most part but it can become difficult to repeat some things. |
| 75 |
|
| 76 |
-- |
| 77 |
Eric Sammer |
| 78 |
Gentoo Linux |
| 79 |
http://www.gentoo.org |
Archives