Re: [RFR] New component to change installer settings
Quoting Frans Pop ([EMAIL PROTECTED]): I'm pretty exited about this as it's something that's on my mind for probably two years now and IMO has the potential to make D-I a lot more user friendly. As Joeyh mentioned, there were discussions about similar ideas in the past and, in short, I like it *a lot*. I actually have no specific comment except that it will make some more stuff to translate, of course...:-) I'd say go for it... signature.asc Description: Digital signature
Re: [RFR] New component to change installer settings
Hi, it would be great if this could become a way to turn the Debian installer into a $DebianCDD installer upon the users request. For the Debian Edu use case, the debian-edu-install udeb would need to be loaded on demand... regards, Holger pgptuvD5b1E7V.pgp Description: PGP signature
Re: [RFR] New component to change installer settings
On Thursday 08 May 2008, Holger Levsen wrote: it would be great if this could become a way to turn the Debian installer into a $DebianCDD installer upon the users request. For the Debian Edu use case, the debian-edu-install udeb would need to be loaded on demand... I had not considered that up to now, but I guess we could include a Select CDD config option. The restriction would be that (as things are now) the custom component could only be loaded during anna and not earlier. signature.asc Description: This is a digitally signed message part.
[RFR] New component to change installer settings
I'm pretty exited about this as it's something that's on my mind for probably two years now and IMO has the potential to make D-I a lot more user friendly. The basic idea is to add three new menu items, the first two only displayed at medium priority and only these are executed by default: - initial settings (after locale/kbd-chooser; included in initrds) - additional settings (after anna; loaded by anna) - generic change settings (after finish-install; included in initrds) These settings include all kinds of things that are currently hard to access. Instead of having to pass boot options, users can now just access a settings menu option. Passing boot options remains possible though. The initial settings dialog would include an option Show low priority questions. This means that we could finally change expert mode to medium prio while still leaving users an early, easy option to change to low prio. IMO this fits well with the new syslinux boot menu for x86 which makes passing boot options a lot less obvious. I've implemented three settings as a rough demo: - mouse settings - enabling support for SATA RAID and multipath The first activates a separate dialog that allows to change all three mouse settings we have (and has a dirty hack to activate the new settings: it kills D-I so it gets restarted). The last two are currently just a true/false toggle (they should get a proper yes/no dialog with some explanation of what they do). Note that these are not shown in the initial dialog. Here are some screenshots: - http://people.debian.org/~fjp/tmp/d-i/d-i_settings.png Shows all three current options (third menu entry). - http://people.debian.org/~fjp/tmp/d-i/d-i_settings_mouse.png - http://people.debian.org/~fjp/tmp/d-i/d-i_settings_menu.png Shows the first two new menu items. And here is an image to try for yourself (gtk frontend): - http://people.debian.org/~fjp/tmp/d-i/mini_settings.iso With a default install you'll see nothing. Either backup to the menu or boot in expert mode. To get an idea of how it works, see: - /usr/bin/installer-settings - /usr/lib/settings/*/* Together they IMO show the basic flexibility. It uses a plug-in structure: the SATA RAID/multipath settings come from disk-detect; mouse settings comes from rootskel-gtk. Here are some features I have in mind (some partially implemented, but not in the demo): - remove the initial and additional options from the menu after they have been passed (users can still use the generic menu option) - show some settings only in selected dialogs; example: the show low prio questions option would only be shown in initial settings, while the current debconf-priority could be integrated in generic change - disable showing some settings after some point in the installation - show some settings only once (either in early or in additional) The settings dialog is currently flat, but I plan a two-level structure with headers for main categories and the items indented, and possibly a blank line between categories. Below an overview of candidates for settings support. Some will need discussion. Cheers, FJP P.S. Yes, it uses the new align feature in cdebconf :-) Overview of potential settings -- * General - show expert questions (in early) - debconf priority (in menu) - rescue mode (in early/additional) - frontend theme - mouse support (device/protocol/left-handed) (in early/menu) * Hardware support - SATA RAID - multipath - PCMCIA support (could help avoid asking multiple times!) * Networking - PPPoE support (in early) - type of configuration (none/static/dhcp) - allow unauthenticated (?) * Installed system - use SUDO instead of root account - create first user * Debian settings (or Package management) - use security (?) - use volatile (?) - use contrib (?) - use non-free (?) * Advanced - keep regular virtual consoles (sercon installs) - eject CD - halt/poweroff system instead of reboot Other options * selection of bootloader to use? signature.asc Description: This is a digitally signed message part.
Re: [RFR] New component to change installer settings
A long, long time ago I proposed changing the main menu into a kind of list of settings like this. Language: English Location: United States Network: autoconfigure Disk: autopartition entire disk (hda1) Users: root, joey Software: desktop, print-server Grub: install to MBR, no other OS Finish installation Select a menu item to configure it, thereby running the menu item at medium priority, or skip over it if the default setting looks good (and skipped over menu items would run noninteractively at high[1] priority as needed to satisfy dependencies). Once you have such a menu, it's easy to add things to it, without them getting in the way unduely. As long as there arn't *too* many. Language: English Location: United States Mouse: PS/2 Theme: foo Network: autoconfigure Disk: hda1, autopartition entire disk Users: root, joey Software: desktop Grub: no other OS Finish installation Expert mode: disabled Rescue mode: disabled Of course, submenus could also conceivably branch off of this. Frans Pop wrote: Overview of potential settings -- * General - show expert questions (in early) - debconf priority (in menu) - rescue mode (in early/additional) - frontend theme - mouse support (device/protocol/left-handed) (in early/menu) Having these things in a submenu makes sense, I think, both in the current installer, and in the context of the above wild idea. * Hardware support - SATA RAID - multipath - PCMCIA support (could help avoid asking multiple times!) * Networking - PPPoE support (in early) - type of configuration (none/static/dhcp) - allow unauthenticated (?) * Installed system - use SUDO instead of root account - create first user * Debian settings (or Package management) - use security (?) - use volatile (?) - use contrib (?) - use non-free (?) * Advanced - keep regular virtual consoles (sercon installs) - eject CD - halt/poweroff system instead of reboot I'm not convinced that it makes sense to have a menu with these things on it, rather than just asking the questions at relevant times with appropriate priorities. To what extent are the problems this is trying to solve due to us having gotten into the bad habit of adding debconf settings but never actually displaying a question for them? It can be annoying to have to go through the installation at low priority to be able to answer a single low-priority question, but this menu does not, and cannot, contain every possible low-priority question, so it doesn't eliminate that annoyance entirely. And in cases of UI changes like these, it often makes sense to do the whole change, or no change; leaving things in a half-way state means added complexity. PS, why do we need to worry about which hand the mouse is configured for? AFAIK the GUI frontend only uses a single mouse button, so why not treat left and right clicks the same? -- see shy jo [1] This was before priority inflation. signature.asc Description: Digital signature
