todo-list.md

@@ -107,22 +107,22 @@ Stuff not yet or barely started, to investigate, to consider, whatever:
  - [ ] 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.
  - [ ] dpkg-divert gives a warning about redirections which we are doing, which would be nice to suppress.
- - [ ] 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. The change mentioned above regarding avoiding running every script through the frontend could help here.
+ - [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).
  - [ ] Consider the issue discussed in the mailing list recently of the fact that Debian live images cannot be uniquely identified, such that from EFI (or perhaps rather secure boot) loading, the stub `grub.cfg` that searches for the main image filesystem can find that of a completely different image. This impacts both situations of having multiple images (CDs/DVS/pendrives) in the computer at the same time (uncommon) but also solutions like rEFInd that place multiple images onto a pendrive for selection from an EFI menu. I've been meaning to get back to the person I was discussing stuff with for several days.
  - [ ] Updating the manual (`live-manual`, not manpages!).
    Another contributor has privately already been working towards this, so I'm waiting upon the results of their work before contemplating any significant fixes and rewrites myself. I've just submitted the odd minor fix here and there.
- - [ ] Moving the manual (`live-manual`) away from SiSu format to something much more modern and common.
+ - [ ] Moving the manual (`live-manual`) away from SiSu format to something much more modern and common. (IF agreed upon).
  - [ ] Possibly tweaking the manual design a little to make it look nicer.
  - [ ] Consider removal of the ability to build without using the chroot (the option after all insists that users never try). Is it worthy of removal? Does it even work?
  - [ ] Consider whether ability to run from local folder is useful enough to keep? Was it just for development purposes? (Keeping such features is a maintenance burden).
- - [ ] Consider whether the bootloaders solution involving all of the stuff in `functions/bootloaders.sh` is really a good idea, whether there's something more simple that could be implemented in the config validation checks or something instead.
+ - [ ] Possibly replacing the stuff in `functions/bootloaders.sh` with config validation checks.
  - [ ] Maybe consider meson support as a more modern and preferable alternative to autotools?
  - [ ] I encountered a reference somewhere to livebuild 4.x not liking certain config files that start with logic, so a less helpful item in my offline todo list states. Is this still so? If so look into fixing.
  - [ ] Check whether it is correct for the `live/filesystem.packages` file to exist in the final image, similarly the `live/filesystem.packages-remove` file.
  - [ ] Check out xorriso warnings about too long string lengths.
  - [ ] Check out the xorriso `-no-emul-boot` option being duplicated twice in the options given to it.
- - [ ] In some scripts involving `_PASS` variables and similar, for an invalid value, `Usage()` is simply called, which is not necessarily clear/helpful. Consider adding error, possibly dropping `Usage()` output.
+ - [x] In some scripts involving `_PASS` variables and similar, for an invalid value, `Usage()` is simply called, which is not necessarily clear/helpful. Consider adding error, possibly dropping `Usage()` output.
  - [ ] Consider adding a warning if user config wants firmware, but has not added contrib/non-free archive areas to remind them that they will only be getting a subset if they do not correct this?
  - [ ] When you execute a component script directly, there is no message output at the end to confirm that it completed successfully rather than failed without visible error. We would not want such a message normally. Consider how to accomplish printing such only when wanted, involving preferably an exit trap (which must not conflict with the one for removing the lock). It should also of course give a similar clear message on failure.
  - [ ] Consider locking of `lb clean` and `lb config`. `lb config` does not use the lock at all, and so can be run in the middle of a build. `lb clean` is similar, it just deletes the lock early on (which may be useful for recovery purposes, but allows running during build).