Comment 7 for bug 1385410
Revision history for this message
| Matthew Paul Thomas (mpt) wrote Re: [system updates] hook into system-image updates to precompile policy prior to reboot | #7 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
bbfa235
(Get the code!)
The spec already includes a determinate progress bar when installing system updates. Unfortunately, this isn't implemented yet. <https:/
According to bug 1359344, the update itself happens after the restart. So if the precompilation happens after the restart too, that would be fine. If the precompilation happens before the restart, that would be a bit worse, but not terrible: the progress bar could advance from 0 to 40% (for example) for the precompilation, then the device could restart, then (assuming that the restart took 5% of the time) the progress bar could reappear, advancing from 45% to 100%. You wouldn't be able to do anything else during the installation, so that the device restarted in the middle would be merely an implementation detail.
That disappearance and reappearance of the progress bar would be worthwhile if it allowed for faster updates overall: for example, if the precompilation could begin, or even complete, before the rest of the system image downloaded or before you decided that now was a good time to restart.
So to design this, I need the answers to three questions:
A. Is it practical to use the device while precompilation is happening in the background?
B. What drawbacks, if any, are there from using the device after precompilation finishes, but before the device restarts?
C. When recompilation is required, what proportion of overall update installation time, on average, is taken up by (i) the precompilation (ii) the restart (iii) the flashing (iv) anything else? (Bonus points if you manage to relate (i) to the number or size of the policies.)