The man page has:
manpg> NAME
manpg> jigdo-lite - Download jigdo files using wget
manpg>
manpg> SYNOPSIS
manpg> jigdo-lite [ URL ]
The help page has:
help> Usage: /usr/bin/jigdo-lite [OPTIONS] [FILES or URLS...]
Man page problems:
The man page incorrectly implies that local files cannot be supplied
with a simple filename -- that they must be in an URL format. The
short description in the first section incorrectly implies that this
“lite” tool is only used to fetch the *.jigdo files and nothing
else. It would be better to write something like:
“Downloads jigdo metadata (if needed) and the payload data specified by it (as needed).”
Help page problems:
The BNF is incorrect but probably understandable enough to most. The
flaw is that -h and -v are mutually exclusive to everything
else. This would be more accurate:
Usage: /usr/bin/jigdo-lite [-h|-v|[OPTIONS] [files|URLS...]]
Judging from this line in the config: “jigdoOpts='--cache jigdo-file-cache.db'”,
--cache is also an option. It is missing in both the help page and man page.
mini how-to problems from file:///usr/share/doc/jigdo-file/debian-jigdo-mini-howto.html:
This might have been accurate in 2005 but these days HTTP is the
*worst* as far as being encumbered by blockades and countless
varieties of enshitification. I’m surprised rsync is said to have such
issues, but I find FTP to be less prone to nannying obstacles.
Considering jigdo is not limited to large Debian images, it seems a
bit off to tell users what networks they should not be using jigdo
on. Although it is a Debian how-to, jigdo could be used to do a small
update.
That statement is 20 yrs old; probably should be removed.
It would be good to mention xorriso in this section. Perhaps reference https://wiki.debian.org/MergeDebianIsos
That’s inconvenient. I can only imagine name clashing in $CWD with
jigdo-file-cache.db. Is that the issue? Is the DB unable to handle
concurrency? If true, then --cache should be documented because it
would enable multiple instances to share the same $CWD.
The current answer ignores the fact that the config file is
hard-coded. It’s surprising that that is not a problem. Isn’t there a
race condition with the config file whereby concurrent instances would
be affected by each other’s settings?
It’s worth noting that it would be very useful for each concurrent
jigdo instance to pull from a different mirror. The hard-coded config
file complicates that for non-interactive launches. IIUC, each
instance would need a TCL/Expect wrapper script to supply a different
mirror. Correct? Maybe this should be mentioned in the mini how-to.
intensive, so you will want to use nice and ionice commands when
simultaneously using your computer’s UI.”