| 1 |
On Tue, 2006-10-17 at 21:19 -0400, Preston Cody wrote: |
| 2 |
> Quickstart will become the primary method for automated installations. |
| 3 |
> It is designed to be able to be netbooted and will be the installer |
| 4 |
> integrated into Scire. It may also be added to the minimal livecd at |
| 5 |
> some point (why not, right?). Quickstart works with blank drives |
| 6 |
> only, and is not too user-friendly. Currently no frontend or |
| 7 |
> configurator exists though I have plans for a web-based one that will |
| 8 |
> plug in to Scire nicely. |
| 9 |
|
| 10 |
Sounds good. It would be nice to have at least one interface that isn't |
| 11 |
web-based, but that's not vital. |
| 12 |
|
| 13 |
> GLI will be refactored to become slightly more interactive. There |
| 14 |
> will probably be about four main steps/stopping points/actions that |
| 15 |
> will occur. |
| 16 |
|
| 17 |
Hrrmn... |
| 18 |
|
| 19 |
> 1. Setup networking, logfiles, chroot_dir and such.. i.e. all the |
| 20 |
> client_configuration stuff. This already is done interactively from |
| 21 |
> the two main frontends. We can thus chuck the entire client_profile |
| 22 |
> (yea!!!!) |
| 23 |
|
| 24 |
Are we talking things like net-setup? What exactly are we talking about |
| 25 |
using here? |
| 26 |
|
| 27 |
> 2. Drop to cfdisk or diskdruid to let the user do partitioning and |
| 28 |
> probably filesystem formatting too. This lets the user deal with |
| 29 |
> partitioning themselves and thus we don't get the blame when they |
| 30 |
> screw it up! :) |
| 31 |
|
| 32 |
That's probably a good idea, but really sucks for the people that don't |
| 33 |
know what they want. That was the nice thing about the current GLI, |
| 34 |
being able to click that "Recommended" button. Of course, you could |
| 35 |
limit the "Recommended" concept to only work with known-good |
| 36 |
partitioning schemes. |
| 37 |
|
| 38 |
For example: |
| 39 |
|
| 40 |
blank drive - we know we can partition this |
| 41 |
1 primary partition (and free space) - we know we can handle this |
| 42 |
|
| 43 |
...and that's about it. You would cover a vast majority of the users |
| 44 |
with this option. I would think (using the GTK+ installer as an |
| 45 |
example) that having something like the current partitioning screen + an |
| 46 |
"Advanced" button, which drops to a shell to allow the user to partition |
| 47 |
manually, using pretty much anything that they want (LVM, EVMS, DMRAID, |
| 48 |
MDRAID) would cover all the bases. I think having it as "opt-in" on the |
| 49 |
"easy" screen and only allowing known-good configurations should resolve |
| 50 |
most of the issues with partitioning. |
| 51 |
|
| 52 |
> 3. Define mountpoints.. these will replace the partition layout in the |
| 53 |
> install profile. Then we fetch/install the stage tarball and/or |
| 54 |
> portage. We will still keep the dynamic stage3 (as well as making |
| 55 |
> command-line tools for its use), because the installer-livecd isn't |
| 56 |
> changing. Having this step separate lets us choose profiles and |
| 57 |
> gather updated info about things like USE flags. |
| 58 |
|
| 59 |
I like it. |
| 60 |
|
| 61 |
> 4. Everything else. There really isn't much benefit to separate out |
| 62 |
> the rest of the steps. We'll let people drop to a shell to make their |
| 63 |
> own kernel config, but I don't see much beyond that and I still like |
| 64 |
> the ability to configure at once and then let it go for a while. |
| 65 |
|
| 66 |
Absolutely. I think the "configure and forget" aspect of the installer |
| 67 |
is one of its greatest strengths. |
| 68 |
|
| 69 |
> These changes will drastically simplify the partitioning code and make |
| 70 |
> GLI much easier to port to other architectures. |
| 71 |
|
| 72 |
One thing that I have never understood is why all of GLI is in python. |
| 73 |
Take catalyst as an example. It uses python for the places where python |
| 74 |
does best and uses bash for the rest. It makes it very easy to |
| 75 |
understand when it calls out to smaller, interchangeable scripts for |
| 76 |
sub-tasks. I'm not saying that this is what the GLI needs to do, but it |
| 77 |
could definitely make things easier, and also reduce the memory |
| 78 |
footprint of GLI, when loaded. |
| 79 |
|
| 80 |
> The plan is to release a version of GLI like it is now with bugfixes |
| 81 |
> only for 2007.0 and target the new GLI (god forbid, should we call it |
| 82 |
> GLI 2.0? <cringe>) for 2007.1. If enough progress has been made, we |
| 83 |
> can try to put an experimental copy on the livecd and hide it (doesn't |
| 84 |
> make much sence to have an entirely different /experimental livecd |
| 85 |
> just for that). The new GLI will be written first and foremost with |
| 86 |
> gli-dialog as the frontend. The GTK frontend is quite bloated and a |
| 87 |
> pain to change and maintain, so it may disappear entirely and that is |
| 88 |
> ok by the installer devs. |
| 89 |
|
| 90 |
That's OK by me, too. We'll get some flak for it, I'm sure, but at this |
| 91 |
point, I don't think we can do *anything* without getting flak, so our |
| 92 |
best course of action is to just do what we think is best. |
| 93 |
|
| 94 |
> That's about it, if you have any questions/comments, feel free to post |
| 95 |
> them. This list has like no traffic so it could use some discussion |
| 96 |
> every once and awhile. |
| 97 |
|
| 98 |
Well, if you jokers didn't discuss everything on IRC... ;] |
| 99 |
|
| 100 |
-- |
| 101 |
Chris Gianelloni |
| 102 |
Release Engineering Strategic Lead |
| 103 |
Alpha/AMD64/x86 Architecture Teams |
| 104 |
Games Developer/Council Member/Foundation Trustee |
| 105 |
Gentoo Foundation |
Archives