Major GLI Redesign!
"Preston Cody" <[email protected]> Tue, 17 Oct 2006 21:19:51 -0400
| Newsgroups | gmane.linux.gentoo.installer |
|---|---|
| Message-ID | <[email protected]> |
Greetings and salutations, In GLI's 2.5 years or so of existence, we have achieved almost all of the goals of the project. The first main goal of GLI was to make a fully automated installation program that would work off of profiles, be non-interactive, and architecture-generic. The other main goal was to make an installer that could be used by end users for their desktops without having to know XML and with pretty, easy-to-use frontends that would help boost the reputation of Gentoo as not just a super-l33t distro. We have struggled and faught hard to achieve both goals at the same time, but alas they are simply too different to be able to handle both and do a *good job* at both. The main problem, as was to be expected, is partitioning. Andrew Gaffney has spent ages working on trying to support every insaine and idiotic combination of partitions that users try to create, but there are millions of combinations and the simple truth is we can't do it right for everyone, and we're tired of the endless stream of people complaining why their drive with 6 primaries isn't being supported. Also, with the current partitioning, it is extremely hard to support raid or lvm or other architectures in general for that matter. After seeing the simplicity and ease of Quickstart, the solution became clear: admit failure and split/branch GLI. So here's the plan: 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. 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 (yea!!!!) 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! :) 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. 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. These changes will drastically simplify the partitioning code and make GLI much easier to port to other architectures. 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 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. Have a pleasant day, -Codeman -Installer Project Co-Lead. -- [email protected] mailing list