Okay, here is a copy rebased onto 5.x. The early package dependency and sparc fix commit dependencies are gone in this one, just leaving the solution itself. The second to last commit adds a gpg/gpg2 dependency.
As previously expressed, cherry picking this back to 4.x is certainly easier IMO, avoiding you (Daniel) having to do the work of carefully reworking the 4.x path onto 5.x as I just did, or merging slightly different copies of the solution to each branch, having to review and compare both. However of course to cherry pick back to 4.x, this requires also bringing at least the following changes with it: - removal of cdebootstrap (or careful merging of my solution in the config script - removal of sparc support - dependency updates in control file (or carefuly merging of my solution in the control file, or ignoring the second to last commit in my 5.x solution in the backport). - the 'LIVE_IMAGE_PARENT_ARCHIVE_AREAS' python cleanup commit (actually the 4.x version was based on this also). In case it's helpful to reviewers, here's a brief high level overview of some aspects of the new solution I'm providing: Apart from Release and Release.gpg which are treated as a pair, files being downloaded and the files needed for verification are downloaded and verified in a chain of function calls. It employs a somewhat smart use of caching. When the build process starts, by default dist-info and installer image files (vmlinuz and inird) are flushed, though the user has control over this with new parameters (and can also optionally flush them via the clean script). Throughout the process, files are reused from the cache if they exist in the cache, but only as long as they pass verification, and as long as verification isn't disabled (which can be done via --wget-secure false, similar to apt). If verification fails (at any point in the verification chain), any cached copies of files that were used are flushed (it keeps track of them for each download), and they are redownloaded for a second try. This means that a mixture of some old (or broken partial downloads) and some new files will not cause a failure, if they should pass, they will, if not, the ones used from the cache will be replaced, and one further verification attempt made. Furthermore it keeps track of files recently verified, so reduce unnecessary work, though unfortunately it can't track across the entire build process due to the fact that each stage is executed through the lb script, which resets the environment (not a big deal though, it still adds some efficiency, particularly in the installer stage). Much of the new code makes use of a new 'Get_cache_path' function, which, providing a more central path compositor, helps reduce mistakes through avoiding code repetition.
718225_lb5.tar.gz
Description: GNU Zip compressed data
