Hi, a quick note before I start: I am no longer maintainer of initial-setup. But since I started it I will answer some of the questions. > the main reason why we still have i-s while it's possible to do these > setup tasks in Anaconda itself are OEM installations. And I'm pretty > sure we don't have many ;-) OEM installations. We (Fedora) probably don't, but we need this functionality for other products as well. Plus there are some (enterprise..) hardware configurations that need special treatment before the first login. > So I agree with - putting as much functionality into Anaconda - licence, > welcome screen, user creation (at least recommend the creation in the > installer) and then there would be no reason to run i-s (unless user > is not created) and system-wide part of g-i-s. It was actually intended to behave this way from the beginning. All the screens are shared with Anaconda (and all we have right now live as part of Anaconda source code). The hide/skip functionality is missing, but there is a proof of concept patch that hides all already configured screens from initial-setup (http://fedorapeople.org/cgit/msivak/public_git/anaconda.git/commit/?h=msivak&id=f679cafc5541b30b31bd5039004b6ccdcae3b54c). > Another reason why I'd prefer this solution are neverending problems with > firstboot/i-s theming under KDE. No theming, initial-setup is the last step of installation and so should be considered DE agnostic. For this reason it also looks the same as the installer. > > So, vpodzime, msivak: can we lobotomize initial-setup? We do not have to, initial-setup is just an empty shell that can execute Anaconda screens (either core screens or plugins, but the API is Anaconda based). Best regards -- Martin Sivák msivak@xxxxxxxxxx Red Hat Czech RHEV-M SLA / Brno, CZ ----- Original Message ----- > ----- Original Message ----- > > 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. > > Well, > the main reason why we still have i-s while it's possible to do these > setup tasks in Anaconda itself are OEM installations. And I'm pretty > sure we don't have many ;-) OEM installations. > > I talked to vpodzime last week about the possibilities - two features > that are still not implemented are for EULA/license and Welcome screen. > Historically it was in firstboot as far as I know, is it the right place? > I'd say no - Anaconda is the first UI you see and with possibility to > finish all steps in one tool, it's non sense. For OEM again - it's different. > > So I agree with - putting as much functionality into Anaconda - licence, > welcome screen, user creation (at least recommend the creation in the > installer) and then there would be no reason to run i-s (unless user > is not created) and system-wide part of g-i-s. > > Another reason why I'd prefer this solution are neverending problems with > firstboot/i-s theming under KDE. > > > 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. > > +1, I think Vratislav will be on board too after our latest > conversation ;-). > > Jaroslav > > > -- > > 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 > -- > devel mailing list > devel@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
