... | ... | @@ -106,6 +106,8 @@ Stuff not yet or barely started, to investigate, to consider, whatever: |
|
|
- [ ] Consider, with the above mentioned change of having stage files checked in major build stages such that they are skipped in recovering and such (if re-running `lb build`), whether this is a sufficient improvement such that there is no longer value to the developer feature of caching stages (other than bootstrap which is always required).
|
|
|
- [ ] The binary stage directly removes the "chroot_archives" stagefile rather than running that 'chroot prep' script in a suitable mode, which is problematic for a bunch of reasons I've got jotted down in my offline todo list file, which I won't bother putting here.
|
|
|
- [ ] If failure occurs in a script that installed packages temporarily for accomplishing some action which it removes at the end, then if the user tries to re-run to recover, the list of installed packages which was held in memory is lost, thus those packages are stuck in place. The list should be recorded in a file such that recovery can be done to restore things correctly.
|
|
|
- [x] Solve the basic problem by saving list in file.
|
|
|
- [ ] Try to improve the solution by ensuring removal does not need to wait for re-run and next execution of remove function.
|
|
|
- [ ] dpkg-divert gives a warning about redirections which we are doing, which would be nice to suppress.
|
|
|
- [x] Config validation is only performed when executing a build if you use `lb build` (typical), not when executing the major stages individually, which some may do.
|
|
|
- [ ] Consider fix for problem of user doing `--foo "foo\"bar"` which ends up as `LB_FOO="foo"bar"` in the saved config files, thus corrupting the file, only fixable by manually editing the file (running live-build loads it causing error). (Though the new `lb config --purge-saved` to be proposed shortly might be able to help here).
|
... | ... | |