[gentoo-desktop-research] Gentoo installer project

[gentoo-desktop-research] Gentoo installer project

[Eric Sammer]

[-- Attachment #1: Type: text/plain, Size: 685 bytes --]

As most of you know, people have been looking into an official Gentoo 
installer. There are a number of projects out there concentrating on 
different areas, but there is an effort to bring them all together. The 
following document covers the general situation and what should / will 
happen if all interested parties are, well, interested and the details 
can be worked out.

http://dev.gentoo.org/~esammer/gentoo_installer_project.txt

Please take a look and share any constructive comments and suggestions.

Also, a new channel has been formed on Freenode so come to 
#gentoo-installer and discuss things there as well.

Regards.
-- 
Eric Sammer
Gentoo Linux
http://www.gentoo.org

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-desktop-research] Gentoo installer project

[dams]

Eric Sammer <esammer@gentoo.org> said:

> As most of you know, people have been looking into an official Gentoo
> installer. There are a number of projects out there concentrating on different
> areas, but there is an effort to bring them all together. The following
> document covers the general situation and what should / will happen if all
> interested parties are, well, interested and the details can be worked out.
> 
> http://dev.gentoo.org/~esammer/gentoo_installer_project.txt
> 
> Please take a look and share any constructive comments and suggestions.

I like the document, thx for this.
For the different architecture, I can test it on ppc on a regular basis.

About server/desktop distinction, I think the default (suggested) packages
installed does matter.

But before this distinction, I'd like your input about the global direction of
the installer :

- should it be minimalist : partitioning, network, install X if desktop
  oriented, and reboot. At first boot, have configuration tools + software
  manager (to install stuff)  displayed. This is what I'd prefer, because there
  is no duplication, and you could call the config step after install.

- should it be complete : partitioning, network, different installation groups,
  full config (net, users, security, server packages, printing, sound, ...)

I think it's interesting to think about that now

wdyt ?

-- 
dams

--
gentoo-desktop-research@gentoo.org mailing list

Re: [gentoo-desktop-research] Gentoo installer project

[Dan Armak]

[-- Attachment #1: Type: text/plain, Size: 1657 bytes --]

On Monday 26 January 2004 11:57, dams@gentoo.org wrote:
> But before this distinction, I'd like your input about the global direction
> of the installer :
>
> - should it be minimalist : partitioning, network, install X if desktop
>   oriented, and reboot. At first boot, have configuration tools + software
>   manager (to install stuff)  displayed. This is what I'd prefer, because
> there is no duplication, and you could call the config step after install.
>
> - should it be complete : partitioning, network, different installation
> groups, full config (net, users, security, server packages, printing,
> sound, ...)

For many configuration purposes it doesn't matter whether you've actually 
booted this system or are in a chroot. You can offer to run the 
configurator/package manager or reboot. (Or even integrate the installer and 
configurator.) If eg a kernel driver is missing, things won't work but won't 
be broken either; we just need to suggest to the user that he should reboot.

What if any things can't be configured normally when in a fully installed 
chroot? Kernel drivers we don't provide in the install environment. And of 
course if the env outside the chroot is eg a live system from another 
partition, you probably don't want to mess with h/w settings. In most cases 
though you shouldn't care whether you configure things before or after the 
first reboot, esp. if you don't actually try to run them.

-- 
Dan Armak
Gentoo Linux developer (KDE)
Matan, Israel
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD  0069 508D 9143 8D5F 8951

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-desktop-research] Gentoo installer project

[Dan Armak]

[-- Attachment #1: Type: text/plain, Size: 1534 bytes --]

On Monday 26 January 2004 07:35, Eric Sammer wrote:
> As most of you know, people have been looking into an official Gentoo
> installer. There are a number of projects out there concentrating on
> different areas, but there is an effort to bring them all together. The
> following document covers the general situation and what should / will
> happen if all interested parties are, well, interested and the details
> can be worked out.
>
> http://dev.gentoo.org/~esammer/gentoo_installer_project.txt
>
> Please take a look and share any constructive comments and suggestions.

From the linked file:
		- The same flexibility as the current manual process with NO loss of
		  any of the options (custom partitioning, file system type selection,
		  individual package selections, etc.). If any option, no matter how
		  seemingly esoteric, is removed, the community will (rightfully)
		  reject the project in its entirety.

AFAICS, the only truly encompassing solution would be to provide an interface 
of sorts to a console. The user could view and edit commands generated by the 
installer, see their raw output, pause operation and insert commands of his 
own, etc. If he wanted to use something not yet provided by the installer, 
he'd just tell it to skip a step and do it manually.

What do you think?

-- 
Dan Armak
Gentoo Linux developer (KDE)
Matan, Israel
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD  0069 508D 9143 8D5F 8951

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-desktop-research] Gentoo installer project

[Eric Sammer]

[-- Attachment #1: Type: text/plain, Size: 2754 bytes --]

dams@gentoo.org wrote:
> I like the document, thx for this.
> For the different architecture, I can test it on ppc on a regular basis.

This is good. The more people on different archs, the more initial 
testing, the more stability, the more happy users.

> About server/desktop distinction, I think the default (suggested) packages
> installed does matter.

Right. It should be (in my opinion) manual package selection by default. 
This is what our (current) users seem to expect, myself included. 
Working primarily with servers, having to choose from groups of packages 
that, no doubt, will contain stuff I don't want in each one is 
problematic and time consuming.

> But before this distinction, I'd like your input about the global direction of
> the installer :
> 
> - should it be minimalist : partitioning, network, install X if desktop
>   oriented, and reboot. At first boot, have configuration tools + software
>   manager (to install stuff)  displayed. This is what I'd prefer, because there
>   is no duplication, and you could call the config step after install.

Minimalist, partitioning, network - absolutely. As for X, I *guess* so 
but again I'm inclined to say give them manual package selection. Since 
dependencies will be autoresolved, the user doesn't have to jump through 
hoops - they just select X. It's the same as giving them a predefined 
set of packages in that with one click, they get X and everything 
required. Same for desktop environment and / or window manager. Again, 
this is all in the interest of a simplified and common environment for 
both server and desktop.

As for rebooting and when, I think the long it can be delayed, the 
better as rebooting (to me) signifies nearing or the end of installation 
and makes me wait for something else. Of course, compiling makes me 
wait, but rebooting is more mentally indicative of being finished.

As for configuration, we can use self destruct tools. Prior to reboot, 
place a configuration controller script in /etc/runlevels/default that 
leads the user through final config (for desktop only - remember that 
server has its unattended post flight config) and when finished, simply 
removes the link, leaving the control script itself, if desired.

> - should it be complete : partitioning, network, different installation groups,
>   full config (net, users, security, server packages, printing, sound, ...)

Of course. The goal is for the user to have to do as little manual post 
flight work but without bloating the pants off of the installer.

> I think it's interesting to think about that now

Yes. These are all design decisions and should be worked out prior to 
"the effort."

Thanks for the comments.
-- 
Eric Sammer
Gentoo Linux
http://www.gentoo.org

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-desktop-research] Gentoo installer project

[Eric Sammer]

[-- Attachment #1: Type: text/plain, Size: 1649 bytes --]

Dan Armak wrote:
> For many configuration purposes it doesn't matter whether you've actually 
> booted this system or are in a chroot. You can offer to run the 
> configurator/package manager or reboot. (Or even integrate the installer and 
> configurator.) If eg a kernel driver is missing, things won't work but won't 
> be broken either; we just need to suggest to the user that he should reboot.

I think that most of these situations are predictable so the user can be 
well informed of such things. In fact, there's very little that I'm 
aware of that *has* to happen post reboot, but I'm certainly willing to 
learn. :)

> What if any things can't be configured normally when in a fully installed 
> chroot? Kernel drivers we don't provide in the install environment. And of 
> course if the env outside the chroot is eg a live system from another 
> partition, you probably don't want to mess with h/w settings. In most cases 
> though you shouldn't care whether you configure things before or after the 
> first reboot, esp. if you don't actually try to run them.
> 

I suppose things such as certain wireless card modules and the like have 
to be built again the *booted* kernel - that's the kind of situation 
were things can / should be done in post flight. I'm starting to think 
that the post flight operations such as additional package installation 
(say postfix, apache, postgres, etc.) and configuration file 
distribution should be done post reboot. Or maybe there's a post flight 
for pre reboot and post - I don't know. These are excellent questions.

Thanks for the comments.
-- 
Eric Sammer
Gentoo Linux
http://www.gentoo.org

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-desktop-research] Gentoo installer project

[Eric Sammer]

[-- Attachment #1: Type: text/plain, Size: 2193 bytes --]

Dan Armak wrote:
> From the linked file:
> 		- The same flexibility as the current manual process with NO loss of
> 		  any of the options (custom partitioning, file system type selection,
> 		  individual package selections, etc.). If any option, no matter how
> 		  seemingly esoteric, is removed, the community will (rightfully)
> 		  reject the project in its entirety.
> 
> AFAICS, the only truly encompassing solution would be to provide an interface 
> of sorts to a console. The user could view and edit commands generated by the 
> installer, see their raw output, pause operation and insert commands of his 
> own, etc.

While I believe that being able to pause between steps and drop to a 
shell is a useful feature (especially for those learning), I don't think 
it's absolutely required. What I mean by same flexibility is to allow 
for individual package selection, file system type selection, custom 
partitioning schemes, and other things we get to do during the current 
installs. Some of the installers I've used in the past (thinking of YaST 
from SuSE) have allowed for such things without being overly cumbersome 
to the user. The console installer could, for instance, drop the user 
into cfdisk for custom partitioning (just an example) while the gtk 
client can use a gtk table with very little custom control work to do 
the same.

Someone (klieber, maybe) suggested a console view to display what hte 
installer was actually doing which might not be a bad idea. The Mac OS X 
  installer has a "view log" menu item that displays just about 
everything it's doing down to detected disks and the like. I think 
something like this might be good. The console install can do the same 
by supplying an option to switch to a log view. It's all pretty open ended.

> If he wanted to use something not yet provided by the installer, 
> he'd just tell it to skip a step and do it manually.

That's also interesting.

> What do you think?

I think it raises some good points and ideas. A console view type thing 
might be good for education and interjecting commands during phases of 
installation.

Thanks for your comments.
-- 
Eric Sammer
Gentoo Linux
http://www.gentoo.org

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-desktop-research] Gentoo installer project

[Dan Armak]

[-- Attachment #1: Type: text/plain, Size: 2161 bytes --]

On Monday 26 January 2004 16:33, Eric Sammer wrote:
> While I believe that being able to pause between steps and drop to a
> shell is a useful feature (especially for those learning), I don't think
> it's absolutely required. 

I think it's useful beyond learning. You can never provide for _all_ 
situations in the installer frontend. In fact, I agree with my reading of 
your document: that the installer should somehow allow for _all_ situations, 
even those we don't foresee. So I think we should at least let the user skip 
any step, pause and access a shell at any point.

My idea in fact was to provide as much freedom as possible - tell the user 
what we think he should do but never force him, even with things like step 
ordering and doing a step twice. The user shouldn't have to know what to do 
next, but if he does know better than the installer he should be able to 
override its suggestions.

With such a design you could still provide interfaces for whatever you wanted, 
and the average user wouldn't ever know about it, but in exotic setups the 
installer would still be mostly useable; it wouldn't be an all-or-nothing 
thing.

> Someone (klieber, maybe) suggested a console view to display what hte
> installer was actually doing which might not be a bad idea. The Mac OS X
>   installer has a "view log" menu item that displays just about
> everything it's doing down to detected disks and the like. I think
> something like this might be good. The console install can do the same
> by supplying an option to switch to a log view. It's all pretty open ended.

To me this is a must-have feature. When something goes wrong, this display is 
necessary for a meaningful bugreport - think "emerge glibc dies 1h27m after 
starting" errors. We also need to be able to display the output of config 
commands in case of errors. Finally, this can be a temporary measure until we 
have proper emerge progress bars.

-- 
Dan Armak
Gentoo Linux developer (KDE)
Matan, Israel
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD  0069 508D 9143 8D5F 8951

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-desktop-research] Gentoo installer project

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 811 bytes --]

On Monday 26 January 2004 15:16, Eric Sammer wrote:
> I suppose things such as certain wireless card modules and the like have
> to be built again the *booted* kernel - that's the kind of situation
> were things can / should be done in post flight. I'm starting to think
> that the post flight operations such as additional package installation
> (say postfix, apache, postgres, etc.) and configuration file
> distribution should be done post reboot. Or maybe there's a post flight
> for pre reboot and post - I don't know. These are excellent questions.

In a testing chroot one can assume these to just work. Maybe a flag to the 
configuration program could be used (or something similar)

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-desktop-research] Gentoo installer project

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 728 bytes --]

On Monday 26 January 2004 14:37, Eric Sammer wrote:
>
> Right. It should be (in my opinion) manual package selection by default.
> This is what our (current) users seem to expect, myself included.
> Working primarily with servers, having to choose from groups of packages
> that, no doubt, will contain stuff I don't want in each one is
> problematic and time consuming.

I think we might order the packages on their leaf status. you normally 
wouldn't want to select glibc as a package to include. If you want X you 
normally just select your windowmanager etc. Maybe we could even provide some 
grouping.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-desktop-research] Gentoo installer project

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 729 bytes --]

On Monday 26 January 2004 12:10, Dan Armak wrote:

> AFAICS, the only truly encompassing solution would be to provide an
> interface of sorts to a console. The user could view and edit commands
> generated by the installer, see their raw output, pause operation and
> insert commands of his own, etc. If he wanted to use something not yet
> provided by the installer, he'd just tell it to skip a step and do it
> manually.

This comes very close to my "split-screen-installer" idea where the bottom 
would be a console and the top a helper function (ranging from simple docs to 
something way more advanced)

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-desktop-research] Gentoo installer project

[Eric Sammer]

[-- Attachment #1: Type: text/plain, Size: 825 bytes --]

Paul de Vrieze wrote:
> I think we might order the packages on their leaf status. you normally 
> wouldn't want to select glibc as a package to include. If you want X you 
> normally just select your windowmanager etc. Maybe we could even provide some 
> grouping.
> 
> Paul

This is one of those situations that's bound to be a little messy. If we 
group packages ala gnome desktop, kde desktop, office utilities, server 
daemons, etc. we're begging to upset users. I'm also thinking that 
presenting them with a portage tree and telling them to go to town might 
be tough too (for new users). I don't know what the right answer is 
here. Personally, I would like to be able to select individual packages 
and have it grey out the dependencies as I do so.

But that's me.

-- 
Eric Sammer
Gentoo Linux
http://www.gentoo.org

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-desktop-research] Gentoo installer project

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 1106 bytes --]

On Mon, 2004-01-26 at 15:11, Paul de Vrieze wrote:
> On Monday 26 January 2004 14:37, Eric Sammer wrote:
> >
> > Right. It should be (in my opinion) manual package selection by default.
> > This is what our (current) users seem to expect, myself included.
> > Working primarily with servers, having to choose from groups of packages
> > that, no doubt, will contain stuff I don't want in each one is
> > problematic and time consuming.
> 
> I think we might order the packages on their leaf status. you normally 
> wouldn't want to select glibc as a package to include. If you want X you 
> normally just select your windowmanager etc. Maybe we could even provide some 
> grouping.

I like the leaf idea, as long as each leaf is provided with a short
description as some of the names aren't immediately obvious.

If we get dependencies auto-selected and -deselected, this could work
out pretty well.

We should have a few sane groupings like "Desktop," "Workstation"
(desktop plus any extra development stuff) and "Server" as well as a
"Custom" where everything is manual.

Donnie

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-desktop-research] Gentoo installer project

[Eric Sammer]

[-- Attachment #1: Type: text/plain, Size: 524 bytes --]

Paul de Vrieze wrote:
> This comes very close to my "split-screen-installer" idea where the bottom 
> would be a console and the top a helper function (ranging from simple docs to 
> something way more advanced)

I could see something like this in the same format as a development IDE 
with a build window below the text editor. The more I think about it, 
the more have a console view with pausable stages is a good thing. It's 
useful for debugging and testing as well.

-- 
Eric Sammer
Gentoo Linux
http://www.gentoo.org

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-desktop-research] Gentoo installer project

[foser]

On Mon, 2004-01-26 at 06:35, Eric Sammer wrote:
> http://dev.gentoo.org/~esammer/gentoo_installer_project.txt
> 
> Please take a look and share any constructive comments and suggestions.

Besides the fact that the document disregards most of the discussion
here on the D&R list so far concerning an installer. It -in my opinion-,
like most other installer projects (except pen2), describes an installer
that is a full replacement for the current installation process, which i
think shoots way beyond the target audience of an installer.

- foser


--
gentoo-desktop-research@gentoo.org mailing list

Re: [gentoo-desktop-research] Gentoo installer project

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 995 bytes --]

On Mon, 2004-01-26 at 15:15, Paul de Vrieze wrote:
> On Monday 26 January 2004 12:10, Dan Armak wrote:
> 
> > AFAICS, the only truly encompassing solution would be to provide an
> > interface of sorts to a console. The user could view and edit commands
> > generated by the installer, see their raw output, pause operation and
> > insert commands of his own, etc. If he wanted to use something not yet
> > provided by the installer, he'd just tell it to skip a step and do it
> > manually.
> 
> This comes very close to my "split-screen-installer" idea where the bottom 
> would be a console and the top a helper function (ranging from simple docs to 
> something way more advanced)

I say we just have a button somewhere that replaces a certain area of
the screen with a console and can switch back when the user is done
using console for whatever reason.

We'd also need a way to skip certain steps of the installation, since
they could be done in "manual mode."

Donnie

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-desktop-research] Gentoo installer project

[Donnie Berkholz]

[-- Attachment #1: Type: text/plain, Size: 880 bytes --]

On Mon, 2004-01-26 at 15:22, foser wrote:
> On Mon, 2004-01-26 at 06:35, Eric Sammer wrote:
> > http://dev.gentoo.org/~esammer/gentoo_installer_project.txt
> > 
> > Please take a look and share any constructive comments and suggestions.
> 
> Besides the fact that the document disregards most of the discussion
> here on the D&R list so far concerning an installer. It -in my opinion-,
> like most other installer projects (except pen2), describes an installer
> that is a full replacement for the current installation process, which i
> think shoots way beyond the target audience of an installer.

I think the reason a lot of people switch to Gentoo is what they hear
about the customizability and flexibility. If we take that away from
them in the first thing they do (using the installer), they might decide
Gentoo wasn't such a good idea after all.

Donnie

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-desktop-research] Gentoo installer project

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 1952 bytes --]

On Monday 26 January 2004 21:21, Eric Sammer wrote:
> Paul de Vrieze wrote:
> > This comes very close to my "split-screen-installer" idea where the
> > bottom would be a console and the top a helper function (ranging from
> > simple docs to something way more advanced)
>
> I could see something like this in the same format as a development IDE
> with a build window below the text editor. The more I think about it,
> the more have a console view with pausable stages is a good thing. It's
> useful for debugging and testing as well.

I really am thinking of a fully functional console (that does not need to be 
used)

In ascii art it would look something like, where next would just take you to 
the next screen. Maybe the top part could also have a vertical split with 
options on the left and the handbook on the right (automatically put on the 
right section)
__________________________________________________________
|      Partition the hard-disk                           |
|                                                        |
|     [parted]                       [qparted]           |
|                                                        |
|     [fdisk]                        [cfdisk]            |
|                                                        |
|                                                        |
|  [previous]                                    [next]  |
----------------------------------------------------------
| #                                                      |
|                                                        |
|                                                        |
|                                                        |
|                                                        |
|________________________________________________________|

Paul
-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-desktop-research] Gentoo installer project

[Paul de Vrieze]

[-- Attachment #1: Type: text/plain, Size: 1482 bytes --]

On Monday 26 January 2004 21:22, Donnie Berkholz wrote:
> On Mon, 2004-01-26 at 15:15, Paul de Vrieze wrote:
> > On Monday 26 January 2004 12:10, Dan Armak wrote:
> > > AFAICS, the only truly encompassing solution would be to provide an
> > > interface of sorts to a console. The user could view and edit commands
> > > generated by the installer, see their raw output, pause operation and
> > > insert commands of his own, etc. If he wanted to use something not yet
> > > provided by the installer, he'd just tell it to skip a step and do it
> > > manually.
> >
> > This comes very close to my "split-screen-installer" idea where the
> > bottom would be a console and the top a helper function (ranging from
> > simple docs to something way more advanced)
>
> I say we just have a button somewhere that replaces a certain area of
> the screen with a console and can switch back when the user is done
> using console for whatever reason.
>
> We'd also need a way to skip certain steps of the installation, since
> they could be done in "manual mode."

Take a look at my reply I just send to esammer.

of course it would be even nicer if the user could disable the console if 
wanted (starting with it would make it's existence obvious). I think it is to 
be preferred to ctrl-f1 style "console-access" like in redhat-6.x (last 
installer I used)

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@gentoo.org
Homepage: http://www.devrieze.net

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-desktop-research] Gentoo installer project

[Eric Sammer]

[-- Attachment #1: Type: text/plain, Size: 2700 bytes --]

foser wrote:
> Besides the fact that the document disregards most of the discussion
> here on the D&R list so far concerning an installer. 

I didn't think it did that and if it did, it was because we have to find 
out if all projects involved can come to a reasonable method of 
integration before we do anything else. It's just a document to help 
explain why we would bring all three together. A general understanding 
of each project is assumed and for those that don't know them, links are 
provided as well as a short description.

> It -in my opinion-,
> like most other installer projects (except pen2), describes an installer
> that is a full replacement for the current installation process, which i
> think shoots way beyond the target audience of an installer.

As for replacing the current process, that is not the idea. The idea is 
to open up Gentoo to people who do not like, do not wish to repeat, or 
do not have time to repeat the current process and there are a number of 
those people. Many of them were at LWE. Of course, that's not really the 
point, either. The console is always going to be there as will the 
documentation; no one is looking to replace that and mandate some new 
method of installing machines. This is another option for those that 
want it. For those people with 300+ machines, the current process 
doesn't exactly scale and this kind of project was desirable. That's all.

With regard to the target audience, there are two, yes. There are people 
who want to install desktop systems using a graphic installer and those 
that want an automated, unattended system. The processes vary to only a 
small degree and being able to work from both a common code base and 
community will not hurt any of the parties involved. Neither will take 
precedence or overshadow the other. Neither is more important than the 
other. I don't think it's unreasonable to work together on a project 
that is beneficial to both types of users. Gentoo, itself, takes both 
types of users into account already and extending the same thought 
process to a project such as an installer works.

I understand that some people don't want an installer and other don't 
want an automated installer and others don't want a GUI installer, ad 
infinitum. No one will be forced to use either and with the amount of 
people involved, working on a combined system should not detract from 
either. If everyone involved in the three projects remains involved (and 
I hope they do) we'll have 6+ people coding. That's a large enough team 
to work on a project that is modular enough to be worked on by that many 
people when separated properly.

-- 
Eric Sammer
Gentoo Linux
http://www.gentoo.org

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [gentoo-desktop-research] Gentoo installer project

[Dan Armak]

[-- Attachment #1: Type: text/plain, Size: 1371 bytes --]

On Monday 26 January 2004 22:22, foser wrote:
> Besides the fact that the document disregards most of the discussion
> here on the D&R list so far concerning an installer. It -in my opinion-,
> like most other installer projects (except pen2), describes an installer
> that is a full replacement for the current installation process, which i
> think shoots way beyond the target audience of an installer.

That's why I wrote my orig reply in this thread. I think we should enhance the 
installation process instead of replacing it. We should allow the user to 
tell the installer what to do, skip/repeat/reorder steps and have access to 
the 'real' console all the time where the installer runs its commands and the 
user can run his as well.

I agree that if the installer becomes an all-or-nothing replacement, many 
people won't find it useful or enjoyable.

Also, with a good modular design we can add piece by piece what we think to be 
necessary, and in the other places the installer would just tell the user 
things out of the install howto or not even that. That way we avoid overdoing 
it - writing things our audience doesn't really need.

-- 
Dan Armak
Gentoo Linux developer (KDE)
Matan, Israel
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD  0069 508D 9143 8D5F 8951

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-desktop-research] Gentoo installer project

[Scott Koch]

>That's why I wrote my orig reply in this thread. I think we should enhance the 
>installation process instead of replacing it. We should allow the user to 
>tell the installer what to do, skip/repeat/reorder steps and have access to 
>the 'real' console all the time where the installer runs its commands and the 
>user can run his as well.
>
>I agree that if the installer becomes an all-or-nothing replacement, many 
>people won't find it useful or enjoyable.
>
>Also, with a good modular design we can add piece by piece what we think to be 
>necessary, and in the other places the installer would just tell the user 
>things out of the install howto or not even that. That way we avoid overdoing 
>it - writing things our audience doesn't really need.
>
>  
>
This is the style of installer that would be the best match for 
Gentoo(quoted above).  I think it would be a big mistake to stray far 
from the current process.  As far as I am concerned the console/ 
split-screen installer is a must.  Our main concern should be getting 
the user comfortable with the current install process, instead of 
changing the installer to better fit the user.  The new installer needs 
consist of various add-ons (to the current process) to make the user 
more comfortable ("Holding their hand and walking them through") with 
the install process.  This can be done various ways, the most popular is 
ofcourse gui's.  However, in staying with the Gentoo way of doing things 
nothing should be hidden.  Everything that is done whether on the 
console, via a gui, or we automate it for them, it should be explained 
exactly what is going on.  It should be up to the user wether they use 
the gue or cli. 

I also feel that it is crucial that we keep in mind while going through 
this process that no matter what Gentoo is actually about,  the 
installer will be the deciding factor in whether people give gentoo a 
try or move on to something else.



--
gentoo-desktop-research@gentoo.org mailing list

Re: [gentoo-desktop-research] Gentoo installer project

[Jeremy Maitin-Shepard]

[-- Attachment #1: Type: text/plain, Size: 2938 bytes --]

Scott Koch <scootersmk@chartertn.net> writes:

>> [snip: no all or nothing installer]

>> Also, with a good modular design we can add piece by piece what we think to be
>> necessary, and in the other places the installer would just tell the user
>> things out of the install howto or not even that. That way we avoid overdoing
>> it - writing things our audience doesn't really need.

A possible way to support this would be to separate the
single-user/``desktop user'' installer into a number of executables
which automate or help the user perform a single step.  This executables
could possibly be simple front-ends for libraries, some of which are
also used in other installer configurations, such as the enterprise
environment installer.

Then the user can simply run the program to complete a given step, and
these `helper' programs can be mentioned in the installation
documentation, as is ufed and mirrorselect (IIRC).

The primary issue that I see with this approach is that it might be
desirable for the user, even in a non-scripted (i.e. non-enterprise
environment) install, to be able to enter all information at the
beginning of the process, and then leave the machine unattended during
the remainder of the installation.  One key issue to deal with will be
avoiding problems with config file updating, since there is no easy way
to automate etc-update, but doing so is critical to automated
installation, and more importantly, maintenance of a large number of
Gentoo machines.

> This is the style of installer that would be the best match for Gentoo(quoted
> above).  I think it would be a big mistake to stray far from the current
> process.  As far as I am concerned the console/ split-screen installer is a
> must.

This is supported by screen.  (The installation documentation could
recommend the use of screen)

> Our main concern should be getting the user comfortable with the current
> install process, instead of changing the installer to better fit the user.  The
> new installer needs consist of various add-ons (to the current process) to make
> the user more comfortable ("Holding their hand and walking them through") with
> the install process.

If this is the only purpose for the single-user (``desktop user'')
installer (as opposed to enterprise-environment deployment), it seems
that the documentation serves this purpose already in fact.  A few more
tools, such as ufed, could be helpful, but I have a hard time thinking
of many which are actually needed.  (A network configuration tool could
be useful, but then again, it is quite easy to edit /etc/conf.d/net with
a text editor, and copying /etc/init.d/net.eth0, even for a novice user,
and clearly editing text files as simple as /etc/conf.d/net will be a
necessary task for any GNU/Linux system administrator, or even a
non-system-administrator user.)

> [snip: must not hide anything]

> [snip: installer deciding factor]

-- 
Jeremy Maitin-Shepard

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: [gentoo-desktop-research] Gentoo installer project

[dams]

Paul de Vrieze <pauldv@gentoo.org> said:

> On Monday 26 January 2004 14:37, Eric Sammer wrote:
> >
> > Right. It should be (in my opinion) manual package selection by default.
> > This is what our (current) users seem to expect, myself included.
> > Working primarily with servers, having to choose from groups of packages
> > that, no doubt, will contain stuff I don't want in each one is
> > problematic and time consuming.
> 
> I think we might order the packages on their leaf status. you normally 
> wouldn't want to select glibc as a package to include. If you want X you 
> normally just select your windowmanager etc. Maybe we could even provide some 
> grouping.

The leaf list is a very good idea !

But actually, my concern is that I don't think it's something that is part of
the installation. This should be part of a portage frontend, that could be
called during installation (in chroot), or at first boot.

installation should (imho) install the base system, then reboot (or have a
complete chroot), to let the tasks to be done by configuration tools & portage
tools

-- 
dams

--
gentoo-desktop-research@gentoo.org mailing list