Re: [gentoo-dev] GUI installer

[Jeff Rose]

Well, I'm glad to see that people are interested.  After doing some
initial research I have some thoughts.  First, we should decide on whether
we want to have a terminal or X based installer.  Does anyone know how
well the generic vesa driver works for X?  I personally have battled with
X so many times that I'm not sure I think its worth it for an installer.
(Although we could just use the RedHat stuff for autodetection etc. if we
want to go that direction.)  Besides X we could use ncurses dialog
widgets or another terminal gui package.  I was thinking it would be cool
to use somethine lighter than X like svgalib.  I have no experience with
it and don't know how cross platform (or cross video card) it is, but it
could be a cool solution if a decent widget set is put on top of it.  I'm
not sure if this would lead to more or less work than using X.
	As for choosing stages, that should be a decision made by the user
at install time.  We can very briefly explain how the system works and let
them do what they please.  For the complete novice we can basically have
the "do everything for me" button.  For the supreme hacker we can let them
have it all while still taking care of mundane details.  (For example,
they could choose what file systems they want to use on what partitions,
but that would just be a selection dialog rather than having to type the
commands etc...)  It might be nice if the installer can be exited at any
point so people have the ability to get things rolling quickly but then
tweak things out to their hearts content once its where they want it.
	One of the major pains in the redhat like installers deals with
package selection.  I think it is ridiculous to give people a list of a
thousand packages and tell them to pick.  Especially since the package
documentation is horrible.  Most people probably wouldn't know that its
important for them to have the e2fsprogs installed, for example.  So, this
is the portion of the installer where I see the most room for innovation.
Especially since gentoo has such a unique package system, we should really
try to enable the user as much as possible, rather than just hucking a
bunch of packages into the mix.  I'm still working on ideas, but we should
experiment with all kinds of stuff to get this stage really smoothed out.
	This idea of processor detection makes me think that a whole lot
of detection could go on if we wanted it to.  The thing is detection is
useless unless you can act on what you have detected.  Changing some CPU
related compiler flags is one thing, but what about detecting network,
sound, video, raid, scsi, firewire, printers etc.  This could all get very
tricky real fast.  What about using RedHats kudzu?

Peace,
Jeff


On Sun, 13 Apr 2003, Derek J. Belrose wrote:

> The only problem I see with doing this is how to represent it in a user
> friendly, yet power user accessible fashion.  Maybe if you are using
> anaconda, you could have the power user abilities under "Amazing super
> power user" setting :)
>
> Grabbing the processor isn't difficult, build a small database of known
> processors and compare it to /proc/cpuinfo.
>
> At this point, what would you use for a install?  Stage1, 2 or 3?  Stage
> 3 would be the quickest in my opinion as well giving the user a really
> good launching pad for an optimized system.
>
> Cliff Free wrote:
>
> >I think a GUI installer would be great if done correctly.  The
> >interface, obviously, should be easy to use, but in the spirit of
> >Gentoo, shouldn't limit the user with what he can do.  On a side note, I
> >also think it would be cool to have the ability to detect the processor
> >type(s) and include some optimization flags for the detected
> >processor(s) (I also feel this feature should be able to be toggled so
> >hard-core power-users would still have the option to fine-tune to their
> >heart's content, and that by default the feature would be OFF.  Maybee
> >the detection system would only augment CFLAGS and CXXFLAGS in
> >make.conf. and/or make.conf settings would override what's detected.)
> >Just my 2 cents worth.  Doing this correctly could prove to be a
> >daunting task.
> >
> >On Sun, 2003-04-13 at 01:38, Derek J. Belrose wrote:
> >
> >
> >>Is the Mandrake install system based on RedHat's anaconda?  If it is,
> >>it's nicely written python...but you'll have to seriously hack it to get
> >>rid of the neat little rpm stuff :)
> >>
> >>I'd be willing to help out a bit on this too...gotta get it going for
> >>Gentoo-Sparc :)
> >>
> >>Derek
> >>
> >>Justin Whitney wrote:
> >>
> >>
> >>
> >>>I think some or all of Mandrake's install system is under GPL as well,
> >>>so you might want to check that out.
> >>>
> >>>--Justin
> >>>
> >>>On Fri, 2003-04-11 at 19:04, Jeff Rose wrote:
> >>>
> >>>
> >>>
> >>>
> >>>>Hello,
> >>>>	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?
> >>>>
> >>>>-Jeff
> >>>>
> >>>>
> >>>>--
> >>>>gentoo-dev@g.o mailing list
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>--
> >>>gentoo-dev@g.o mailing list
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>--
> >>gentoo-dev@g.o mailing list
> >>
> >>
>
>
>
> --
> gentoo-dev@g.o mailing list
>


--
gentoo-dev@g.o mailing list