The hook's guard reported "no tcl dir under usr/lib". What sqlite had created
instead was a directory literally named `zipfs:`
<pkgdir>/sqlite/zipfs:/lib/tcl/tcl_library/
The generated Makefile explains itself:
# TCLLIBDIR = where to install the tcl plugin. If this is empty, it
TCLLIBDIR = //zipfs:/lib/tcl/tcl_library/sqlite3.53.4
sqlite asks tcl where its library lives and installs the plugin beside it. In tcl
8.6 that was a real directory. tcl 9 ships its library INSIDE the executable, in
a zipfs mount, so the answer is a path only tcl can open -- and sqlite used it as
a filesystem path, creating a directory whose name contains a colon.
This is the deferred "libtcl8.6 versus our tcl 9.0" item in its final form: not a
version number to update but a change in what tcl considers a path. TCLLIBDIR now
points at a real directory, versioned from tclsh.
--- FR ---
Le garde du hook signalait « no tcl dir under usr/lib ». Ce que sqlite avait créé
était un répertoire littéralement nommé `zipfs:`
<pkgdir>/sqlite/zipfs:/lib/tcl/tcl_library/
Le Makefile généré s'explique lui-même :
# TCLLIBDIR = where to install the tcl plugin. If this is empty, it
TCLLIBDIR = //zipfs:/lib/tcl/tcl_library/sqlite3.53.4
sqlite demande à tcl où vit sa bibliothèque et installe le greffon à côté. En tcl
8.6 c'était un vrai répertoire. tcl 9 livre sa bibliothèque DANS l'exécutable, en
montage zipfs : la réponse est un chemin que seul tcl sait ouvrir, et sqlite l'a
traité comme un chemin de fichiers, créant un répertoire dont le nom contient
deux points.
C'est l'élément différé « libtcl8.6 contre notre tcl 9.0 » dans sa forme finale :
non pas un numéro de version à mettre à jour, mais un changement de ce que tcl
appelle un chemin. TCLLIBDIR vise désormais un vrai répertoire, sa version lue
depuis tclsh.
Assisted-by: Claude Opus 5