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

[Adam Williamson]

On Mon, 2013-05-20 at 13:46 -0400, Matthias Clasen wrote:
> 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.

Only if you didn't create a user in anaconda; if you did, i-s would be
skipped and you'd only see post-user-creation g-i-s. In practice, now
anaconda offers user creation, I suspect most people will just do it
there. And even if the case where you see all three, they wouldn't
really be overlapping each other, each would be doing something
different, so I still don't think it'd be horrible.

> 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.

Yes, and as I mentioned earlier in this thread, the *main* improvement
we can make here is to have i-s do the same thing.

Trying not to sound too snarky, but GNOME's vision of the ideal
installer is fine and good, but it is not a practical vision for
Fedora's installer. We have always had a very capable and featureful
installer and we really need to have one. We can't lobotomize anaconda
into a Ubiquity clone, however 'clean' it would render the design.
(Believe me, the anaconda team would love to do so if it was practical,
they don't _really_ enjoy the week long design whiteboarding sessions).

> 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.

I don't think so, the main issue is really just i-s's replication of
anaconda functionality when it is unnecessary. I still think the design
where we use i-s for any post-install, pre-desktop tasks that are
necessary and then the desktops handle post-login setup would be the
most elegant from a distro perspective, but I'm not wedded to it.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net