anaconda / initial-setup / gnome-initial-setup: can we do this better?

[Matthias Clasen]

On Fri, 2013-05-17 at 14:51 -0700, Adam Williamson wrote:
> On Fri, 2013-05-17 at 14:44 -0700, Adam Williamson wrote:
> > On Fri, 2013-05-17 at 14:25 -0700, Adam Williamson wrote:
> > 
> > > but still, it seems to be worth considering. Alternatively, we could
> > > make i-s behave a lot more like g-i-s: it could dump its 'root password'
> > > and 'date/time' spokes, and only run at all, and only to allow user
> > > creation, if you didn't create a user during anaconda.
> > 
> > Thinking about it more, this really seems to be the way to go. Forcing
> > user creation in anaconda is a problem for someone who wants to do a
> > minimal install with no user account. Doing the above would reduce the
> > paths to something manageable without compromising any existing use
> > cases.
> > 
> > So, vpodzime, msivak: can we lobotomize initial-setup? Can we jettison
> > the root password and time/date spokes, and make it only do user
> > creation, and only run it if a user account was not created during
> > anaconda? That seems to be the path forward to sanity, in my mind
> > anyway.
> 
> Heck, we could even then use initial-setup on GNOME installs too, and
> only use gnome-initial-setup's "user mode". That would give us a really
> consistent model: you set up root pw and/or user account in anaconda or
> initial-setup, and then desktops can have a tool like
> gnome-initial-setup which runs on the first login for a new user, to set
> up the user's environment. It removes all the functionality overlap
> between different tools and gives us a clear and straightforward model
> for testing and development, that is desktop agnostic.

That would give us the worst of all worlds - you'd have to stop and
answer questions 3 times (anaconda, initial-setup and
gnome-initial-setup) during the installation.

For a desktop installation, we (speaking from the GNOME perspective)
really want the installer to be very simple, and ask as few questions as
possible. This vision is explained in more detail here:
https://live.gnome.org/GnomeOS/Design/Whiteboards/Installer

Anaconda is pretty far from that vision, and we've made
gnome-initial-setup deal with the reality of the situation by not
showing steps if we know that the have already been asked by anaconda.

I can understand that you want to make things easier for yourself from a
testing perspective, but you are really just dealing with a symptom
here. The core problem is the we're trying to use a single tool
(anaconda) to deal with many different use cases. As a consequence,
anaconda has to offer many optional tasks which you can choose to ignore
or not, and you can choose to act on them before or after the
installation is done. Your qa nightmare is built right into the design
of the installer - lots of forking paths through those spokes.