Well it now sounds like we're getting into the design issues, so I say
we get something formal started and save the flame-wars for when we're
making design decisions. I like the ideas put-forth so far, and it
seems we have several interested people, so my question is: What's the
On Sun, 2003-04-13 at 16:36, Derek J. Belrose wrote:
> 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
> >- fstab
> >- 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
> >- build
> > 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
Cliff Free <anaranjado@...>
email@example.com mailing list