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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
