I’ve done probably a couple dozen --install-to-root builds over the past few weeks.
Some were in Qubes and some were in VirtualBox.
Some were version 8.2, some 184.108.40.206, some 220.127.116.11.
All were through a Tor internet connection.
I seem to be getting inconsistent build errors at various times, even with the same build configuration.
For example, one time a package dependency is not met and throws an error, and the next time it doesn’t, etc.
It seems like a number of these build errors may often be due to temporary conditions, such as tor/internet interruptions or system resource consumption issues.
Where, by simply waiting a little bit, refreshing Tor circuit, etc, a simple retry of an erred build step might actually succeed instead of fail.
Much of the infrastructure to catch build errors, and pause the script, seems to be in place already. For example, I often press “c + enter” to ignore and continue in my test builds.
I think a “RETRY” option should be added that loops back through and tries the error build step yet again.
For example, along with the other options: “Press r and enter to retry this step.”
Instead of having to either ignore the step after a single attempt or quit the build script entirely, then have to start all over from the beginning.
it seems like a Retry Loop could help correcting and succeeding with some build error conditions on the fly, instead of having to start from the top and hope for the best again.
This retry capability could also help one further sort out real persistent build errors that the project should know about from temporary conditional ones that are individual and fleeting.
Also, it seems that when the build script is using apt-get to download multiple packages, and sometimes fails on one, it doesn’t have error catching infrastructure to handle that.
For example, I recently got:
Err http://security.debian.org/ wheezy/updates/main python-magic i386 5.11-2+deb7u5 [39.1 kB] Connection failed.
The script did not seem to pause for this failed download, where, depending upon the package, something like this maybe could harm the final build and/or spawn additional errors further in the build script which could not be fixed without going back and getting the downloaded package.
So, at some point, maybe adding an error catching and Retry Loop capability to other parts, like these package downloads could be very helpful to ensuring stable and successful builds.