I haven't had any problems with wxPython, and it should be pretty simple
straight through. I do think limiting the stage 3 to X11 is kind of
presumptuious though. My Blade 100 doesn't have a monitor hooked up, so
an X11 install would in fact limit me to a Stage 2 or 1 install.
Anyway, once we get the CLI part, we should be able to design a decent
gui around it.
I want to start a thread on what a gui/cli package manager should do,
what info to present, etc.
Jeff Rose wrote:
>Alright, we are narrowing in. I think starting with a CLI installer makes
>sense because it will allow us to work on the true installation issues
>rather than getting bogged down in gui code. Lets use python. That will
>let us to use both Cursing Cow and Anaconda as great resources for just
>about every step of the installation. Once we feel like everything runs
>smoothly on a variety of boxes then we can work on putting a gui on top.
>(I think wxPython is the best solution. Its clean, quick and extensive.
>We could even use a gui builder to quickly experiment with a variety of
>interface options.) Anyway, that is for later.
> Building the installer as a set of install/configuration modules
>is a great idea. Lets start with defining those modules, and then we can
>work on common code etc. before digging in.
> I propose that we break this whole idea into 3 main sections.
>(Note: This has nothing to do with the stage1,2,3 tarballs.)
>First, we need the basic gentoo installation:
>- partitioning and file systems (RAID support? SCSI cards?)
>- nic detection and module loading (Pretty much complete?)
>- dns, routing, firewall stuff
>- date & time
>- keyboard, mouse, language
>- cpu detection and compiler flags
>- mounting partitions and getting stage tarball setup
>- password & hostname
>- bootloader setup (interfaces to lilo and/or grub)
> Once the basic system is installed we move into part 2,
>initial Portage system installation and configuration:
>- Portage tree sync
>- Setting use flags
>- Kernel configuration
> Now we have a basic system installed. We can reboot into our new
>kernel and start the final, most difficult, stage of installation: package
>selection. Rather than just copying everyone else and making large lists,
>lets try to make this more intuitive. Maybe we could have a few bundles
>that people can select to get rolling quickly, but full control should
>still given to the user. Personally, I would rather just get a
>working gnome/kde installation and then use a gui selection tool rather
>than some clunky ncurses thing. Maybe we could have a very lightweight
>CLI manager that lets you select gnome, kde or just cli. If they use
>gnome or kde then we give them a slick gui manager once X starts up. If
>they use cli then they are probably setting up a server and they can deal
>with using emerge as is.
> After looking through a bunch of code I agree we should really try
>to use a lot of the existing stuff to get things started. The LiveCD
>pretty much does all the very initial stuff. After that we can use the
>cursing cow work to put together the install stage1 and part of stage2.
>For stage 3, I think we should build a python gui (wxPython?) that doesn't
>use kde or gnome specifically. This is where a lot of the experimentation
>will need to go.
>Whooh... What do you say? I'll be graduating in a month so I won't be
>able to work a whole lot until the summer begins, but I think we should
>try to refine this idea/design a lot before diving in and hacking out
>something that just works.
> On Sun, 13 Apr 2003, Alain Penders wrote:
>>The main installer that was being worked on is Cursing Cow. Both developers
>>that were working on it recently left Gentoo, however.
>>If someone wanted to continue it's development, we probably can get the
>>information needed from them. From what I know, it's in pretty good
>>condition... part of it needed to be rewritten, but nothing major.
>>There's at least one (I think two) other installers in CVS, but I have no idea
>>on their status or where they were left at.
>>Building a good installer goes beyond installing Gentoo. For example, if the
>>installer has a module to configure networking, that module should be written
>>so that it works in the installer, but also in an after-install system
>>configuration tool. Installers also need to be able to handle updates or
>>"corrective installs", which means integration with configuration file
>>On Fri, Apr 11, 2003 at 05:04:10PM -0600, Jeff Rose wrote:
>>> I'm pretty new to gentoo, but I am an instant convert. Just a
>>>few months of emerge bliss and now I'm an avid supporter. Anyway, I'm
>>>thinking about starting a summer project and I'm pondering the idea of a
>>>gui installer. I've been looking around a bit and it doesn't look like
>>>anyone is working on one. Is that true? If there isn't already a project
>>>then I think I'll give it a whirl. I know, I know, gentoo is so great
>>>because it allows you to customize and tweak the hell out of everything.
>>>That is completely true. So, an installer would have to allow just as
>>>much but it could take care of the mundane details for those who aren't
>>>interested or knowledgable enough.
>>> I haven't been around to see what people discuss in terms of the
>>>installer so I'm sorry if this is all stuff that you have gone over
>>>hundreds of times. Even more minimal than a gui installer, have you
>>>thought about adding more scripts to do the standard directory setup,
>>>download, chroot... type of stuff?
>>> What do you think?
>>>email@example.com mailing list
>>firstname.lastname@example.org mailing list
>email@example.com mailing list
firstname.lastname@example.org mailing list