On Tue, 2006-10-17 at 21:19 -0400, Preston Cody wrote:
> Quickstart will become the primary method for automated installations.
> It is designed to be able to be netbooted and will be the installer
> integrated into Scire. It may also be added to the minimal livecd at
> some point (why not, right?). Quickstart works with blank drives
> only, and is not too user-friendly. Currently no frontend or
> configurator exists though I have plans for a web-based one that will
> plug in to Scire nicely.
Sounds good. It would be nice to have at least one interface that isn't
web-based, but that's not vital.
> GLI will be refactored to become slightly more interactive. There
> will probably be about four main steps/stopping points/actions that
> will occur.
> 1. Setup networking, logfiles, chroot_dir and such.. i.e. all the
> client_configuration stuff. This already is done interactively from
> the two main frontends. We can thus chuck the entire client_profile
Are we talking things like net-setup? What exactly are we talking about
> 2. Drop to cfdisk or diskdruid to let the user do partitioning and
> probably filesystem formatting too. This lets the user deal with
> partitioning themselves and thus we don't get the blame when they
> screw it up! :)
That's probably a good idea, but really sucks for the people that don't
know what they want. That was the nice thing about the current GLI,
being able to click that "Recommended" button. Of course, you could
limit the "Recommended" concept to only work with known-good
blank drive - we know we can partition this
1 primary partition (and free space) - we know we can handle this
...and that's about it. You would cover a vast majority of the users
with this option. I would think (using the GTK+ installer as an
example) that having something like the current partitioning screen + an
"Advanced" button, which drops to a shell to allow the user to partition
manually, using pretty much anything that they want (LVM, EVMS, DMRAID,
MDRAID) would cover all the bases. I think having it as "opt-in" on the
"easy" screen and only allowing known-good configurations should resolve
most of the issues with partitioning.
> 3. Define mountpoints.. these will replace the partition layout in the
> install profile. Then we fetch/install the stage tarball and/or
> portage. We will still keep the dynamic stage3 (as well as making
> command-line tools for its use), because the installer-livecd isn't
> changing. Having this step separate lets us choose profiles and
> gather updated info about things like USE flags.
I like it.
> 4. Everything else. There really isn't much benefit to separate out
> the rest of the steps. We'll let people drop to a shell to make their
> own kernel config, but I don't see much beyond that and I still like
> the ability to configure at once and then let it go for a while.
Absolutely. I think the "configure and forget" aspect of the installer
is one of its greatest strengths.
> These changes will drastically simplify the partitioning code and make
> GLI much easier to port to other architectures.
One thing that I have never understood is why all of GLI is in python.
Take catalyst as an example. It uses python for the places where python
does best and uses bash for the rest. It makes it very easy to
understand when it calls out to smaller, interchangeable scripts for
sub-tasks. I'm not saying that this is what the GLI needs to do, but it
could definitely make things easier, and also reduce the memory
footprint of GLI, when loaded.
> The plan is to release a version of GLI like it is now with bugfixes
> only for 2007.0 and target the new GLI (god forbid, should we call it
> GLI 2.0? <cringe>) for 2007.1. If enough progress has been made, we
> can try to put an experimental copy on the livecd and hide it (doesn't
> make much sence to have an entirely different /experimental livecd
> just for that). The new GLI will be written first and foremost with
> gli-dialog as the frontend. The GTK frontend is quite bloated and a
> pain to change and maintain, so it may disappear entirely and that is
> ok by the installer devs.
That's OK by me, too. We'll get some flak for it, I'm sure, but at this
point, I don't think we can do *anything* without getting flak, so our
best course of action is to just do what we think is best.
> That's about it, if you have any questions/comments, feel free to post
> them. This list has like no traffic so it could use some discussion
> every once and awhile.
Well, if you jokers didn't discuss everything on IRC... ;]
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee