I guess we can all agree that base-installer's endless series of progress bars could use improvement.. I don't have time to work on this right now, but I know one way to more or less fix them. I applied the same technique to hw-detect to change it from using two progress bars to just one; it was tricky to do some of the math in shell, but should be easy in C. So I'm tossing this idea out in case someone has nothing to do right now and would like to work on it for after beta 2. If nobody does, I will probably work on it after the beta is out. On progress bars: run-debootstrap translates the debootstrap progress stream into debconf progress bars. There are essentially two ways the progress information from debootstrap can be dislayed. The naive way is to start a new progress bar for each new progress id debootstrap dislays; the problem with this approach is it gives the user no clue as to the overall progress as they just see a bewildering series of progress bars. A more sophisticated approach is to use only one logical progress bar, and know about various debootstrap waypoints, using each as it appears to update the bar to a given point, and using the more detailed progress information to keep the bar updating in between. The waypoints we currently care about, and where the progress bar will be when they complete are: 1% DOWNREL downloading release files; very quick 10% DOWNPKGS downloading packages files; time varies by bandwidth; low granularity 15% SIZEDEBS getting packages sizes; high granularity 30% DOWNDEBS downloading packages; run time varies by bandwidth; high granularity 50% EXTRACTPKGS extracting the core packages 90% INSTBASE installing the base system (note: has distirbingly low granularity, but that needs to be addressed in deboostrap, not here) 100% extra packages base-installer's postinst ends by installing some extra packages; this should also be on the same progress bar (currently low granularity, but easy to fix) These numbers can be tuned to make the bar update more smoothly, but it's hard to make it have a constant update velocity accross different install methods, disk speeds, and cpu speeds. So between 30 and 50%, while downloading debs, debootstrap sends us progress commands telling us what the current amount done is, and what the total amount is. For example: P: 7485690 31625258 DOWNDEBS This is 22422934 / 31625258 = 70% of the way done with downloading debs. Since the DOWNDEBS waypoint uses 20% of the progress bar, that scales to 70% of 20, or 14%. So the progress bar should be positioned to 30+14, or 44%. The text of the progress bar would be something like "Downloading packages: Retrieving diff". Since we want to use the same progress bar for both run-debootstrap and for the end of the base-installer postinst, the actual setup of the progress bar should happen in base-installer's postinst. Then run-debootstrap just updates it to 90%, and finally the end of the postinst takes care of updating it to the final waypoint as it does the apt-install stuff. One other thing to look at might be integrating kernel-installer with base-installer (why are the udebs separate?), and adding a new "kernel install" waypoint, to consolidate yet another progress bar. Appendix A: The debootstrap --debian-installer progress stream. As far as I know, there is no other documentation of the data deboostrap outputs on fd 3 if run with --debian-installer (except its source). But then I have not looked too hard. Here is what I have been able to piece together. The stream consists of a number of lines. Each line is of the form: CODE: arg1 [arg2 .. argn] The codes are: P (progress) arg1 is an integer, the current amount done arg2 is the total amount of work that must be done for this progress item arg3 is a unique identifier for the progress item. It may be omitted sometimes. P is generally followed by PA and PF to build up a message to dislay. If they are left off, an earlier info message can be displayed to indicate what is being done. PA (progress arguments) args combine to form the value of one argument PF (progress format) args combine to be a progress format string. PF (progress format) args combine to form a format string. The info arguments are then substituted in turn into the %s tokens in the string to form the message to display to the user to indicate progress. I (info) arg1 is an identifier for the information message in question Generally followed by an IA and IF. IA (info arguments) args combine to form the value of one argument IF (info format) args combine to form a format string. The info arguments are then substituted in turn into the %s tokens in the string to form the message to display to the user to indicate info. E (error) arg1 is the id of the error May be followed by EA, and EF EA (error arguments) args combine to form the value of one argument EF (error format) args combine to form a format string. The info arguments are then substituted in turn into the %s tokens in the string to form the error message. W (warning) arg1 is the id of the warning May be followed by WA, and WF WA (warning arguments) args combine to form the value of one argument WF (warning format) args combine to form a format string. The info arguments are then substituted in turn into the %s tokens in the string to form the warning message. -- see shy jo
Attachment:
signature.asc
Description: Digital signature