Re-debconfage
Hi all, As many of you have likely noticed from the TODO list, the
xserver-xfree86 debconf needs a rewrite. The thing needs to be spec'ed
out in order to do it properly, so that's what this mail is meant to
start. I'd like to try and identify the problems with the current code,
and work out a basic framework for the rewrite in order to deal with
them. So here it goes.
Current Problems
----------------
1) Difficult to maintain, hence the rewrite. This could be due to not
enough componentization within the code as it stands.
2) The MD5SUM solution to parsing is pretty flexible, but still a hack.
3) Does not warn the user to install autodetection tools if they aren't
present
4) Does not take in to account that autodetection tools were added after
a first configure
5) Does not set good defaults in absence of autodetection (framebuffer,
video card, etc)
6) Does not reprioritize questions such as mouse port when they have been
autodetected.
7) http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=207481 for Eduard
Bloch's list of multiple bugs that would be redundant to copy here
Ways to Deal With the Above
---------------------------
1) More componentization of the code. This means more functions and
better defining of interfaces and hiding implementation. Standard
stuff.
2) Copious use of grep, awk, and whatever else in order to do our best to
pull some data out of existing XF86Config-4's. This will have to be
damn well kept from the rest of the code to keep it from becoming an
utter nightmare. I don't know if we can get it to the point where the
MD5SUM goes away, but I'd personally love to see it.
3) Add a simple boolean question at the start after checking for the
existence of all our autoconfig tools. Also check architecture and
include read-edid if its available. This can be done using debconf's
substitution capabilities, so if discover is available but mdetect
isn't for example, we can only show mdetect on the list for the user.
The boolean question will ask if the user wants to exit the install
or continue.
4) Set either a debconf variable or store the information in a file
somewhere. Since it's a debconf issue, I opt for the debconf
variable, even though it skirts close to the "debconf is not a
registry" barrier. If the package is being reconfigured but
autodetection was not available before and is at that time, it should
be used rather than defaulting to the last selection. This is a
continual thorn in my side with people in #debian who don't know to
install mdetect, read-edid, and discover.
5) Alter the defaults depending on what's going on. vesa should
definitely be the video card default, and with 2.6 becoming more and
more prevalent, I say go with /dev/input/mouse as the default for
mouse port. As for the framebuffer... well there's info in Eduard's
mail.
6) This is a simple matter and should just be handled in code. High
priority stuff without detection and low priority with it. The new
installer, as well as the fix for item 3 should make this extremely
workable.
7) It's all in the above link
Basic Skeleton Spec
-------------------
Check for hardware autodetection tools
if they're not present offer the choice to quit (High priority)
Detect hardware and store values for later
Ask about the desired X server (Low priority)
If another xserver is available that we can find, make this high
priority
Ask about video driver (High by default)
Default to discover (Low priority)
If there is no discover, default to what's in the config file as best
we can figure (Stays High Priority)
If there is no config file value that we can find, default to last
selection (Stays High Priority)
If there is no old selection, default to vesa (Stays High Priority)
Ask about identifier (Low Priority)
Check for multiple video cards via discover, becomes high if so
Ask about bus identifier (Low Priority)
Check for multiple video cards via discover, becomes high if so
Ask about memory for video card (Low Priority)
Ask about XKB rule set (High Priority)
Can this be inferred somehow from the system settings to make it low
priority?
Ask about keyboard model (High Priority)
Same as above. Can this be inferred?
Ask about keyboard layout (High priority)
Same as above.
Ask about keyboard variant (Low priority)
Same as above.
Ask about keyboard options (Low priority)
Ask for mouse input port (High priority)
Defaults to mdetect value. (Becomes low priority)
If no mdetect value available, defaults to config file value as best
we can determine (Stays high priority)
If no config file value available, defaults to last debconf value
(Stays high priority)
If no debconf value available, default to /dev/input/mice (Stays high
priority)
Ask for emulation of 3 button mouse (Medium priority)
Can we make this more intelligent somehow to bring the priority down?
Ask for scroll wheel events (Low priority)
Can we just enable these by default and skip the question?
Ask for monitor identifier (Low priority)
Set Generic Monitor1 as default, incrementing the number as need be
Ask if the monitor is an LCD device (High priority)
Monitor Characteristics
This whole section needs filling out. I'd like to hear suggestions.
Extensions Loading
I say make this low priority and just load the good choices by
default, which is basically everything. If any arch-specific enables
or disables need to be done, then do them as required.
Write Sections To Config File (Low Priority)
Same as current.
Ok. There we go. Thoughts?
- David Nusinow
Reply to: