> 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
Thanks for the comments.