Question
tlmgr repository pinning crosses a package database compatibility boundary between TeX Live releases
Kavi Moss
0 reputation · 04 Jul 2020, 23:34 UTC
58.3K views1
Loading…
0 reputation · 04 Jul 2020, 23:34 UTC
TeX Live’s annual release model preserves frozen tlnet-final repositories, and tlmgr option repository can pin an installation to one of these snapshots. The intent is a repeatable package set where tlmgr update --all treats the frozen database as authoritative. However, the transition window between annual releases introduces uncertainty: an unpinned installation may briefly pull next-year pretest packages from the default repository, silently drifting across the compatibility boundary.
A separate version-sensitive boundary exists between the tlmgr binary and the frozen repository it targets. A newer tlmgr pointed at a very old frozen repository may reject the texlive.tlpdb revision or fail signature verification, breaking the repeatable setup. Even when the package database is accepted, pinning only governs managed packages; user-local TEXMFLOCAL and TEXMFHOME trees remain outside the snapshot and can introduce nondeterminism. Format files generated by fmtutil are also tied to the engine binary and package versions, so a frozen package set does not guarantee reproducible formats if the engine is updated separately.
Given these constraints, what is the supported compatibility range between a tlmgr version and a frozen historic repository, and how should a workflow handle the annual transition window to prevent drift? Should the pin be set before or after the default repository switches to pretest content, and what is the recommended way to verify that the local texlive.tlpdb revision matches the intended snapshot?
32775 reputation · 05 Jul 2020, 03:59 UTC
The supported compatibility range is narrow: use a tlmgr binary from the same TeX Live release as the frozen tlnet-final repository, or at most one release ahead. A newer tlmgr pointed at a much older snapshot may reject the texlive.tlpdb revision or fail signature verification. To prevent drift during the annual transition, set the repository pin before the default repository switches to pretest content. Verify the local database revision with tlmgr info texlive and compare it against the known revision for that snapshot.
Confirmed behavior: tlmgr option repository accepts a frozen URL and makes tlmgr update --all treat that database as authoritative. The annual pretest switch is a known event in the TeX Live release cycle.
Likely explanation for the boundary: the texlive.tlpdb schema and repository signing keys evolve between annual releases. A tlmgr more than one year ahead of the frozen repository may encounter a revision number or signature it does not recognize. This is a practical compatibility limit inferred from the release model, not a formally published API contract.
textlnet-final path for the desired release year).tlmgr option repository https://mirror.example.org/texlive/tlnet-finaltlmgr update --dry-runtlmgr info texlivekpsewhich texlive.tlpdbtlmgr info texlive reports the active repository label and the texlive.tlpdb revision. Because revision numbering can change format between TeX Live releases, do not rely on a hardcoded string. Instead, record the expected revision from a trusted installation of the same release year, then compare. The file modification date of texlive.tlpdb should also align with the frozen release date.
Pinning governs only packages managed by tlmgr. User-local TEXMFLOCAL and TEXMFHOME trees remain outside the snapshot and can reintroduce nondeterminism. Format files built by fmtutil are tied to the engine binary and package versions; freezing the package set does not guarantee reproducible formats if the engine is updated separately.
If your tlmgr is more than one release ahead of the target frozen repository, the exact error text from tlmgr update --dry-run determines whether you should install the matching year's tlmgr or whether the failure is limited to signature verification and can be worked around. Without that message, the conservative recommendation is to use the same-year binary.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.