diff --git a/goals/G-066-pkgindex-tm-repackaging.md b/goals/G-066-pkgindex-tm-repackaging.md index ff639349..8da01b06 100644 --- a/goals/G-066-pkgindex-tm-repackaging.md +++ b/goals/G-066-pkgindex-tm-repackaging.md @@ -38,3 +38,29 @@ current goal touches this. characterization - what happens when both shapes of the same package are present), G-063 (license fields in the datafile), G-065 (manifest schema sharing), G-067 (repackaged artifacts as the publish payload). +- 2026-07-21 (user direction: support binary-bearing zip-based .tm as single-file + downloadable libs, and generate them for punkbin). CHARACTERIZED the binary-load + path of a zip-based .tm (modpod) on windows tcl 9.0.5 - specimen: a + #modpod-mybintest-0.1 wrapping a real tcl9thread307.dll, built via + modpod::lib::make_zip_modpod. Findings: the .tm self-mounts (its prepended stub + runs tcl::zipfs::mount //zipfs:/#modpod/...#mounted-modpod--), + then the inner binary 'load's from that zipfs mount and EXTRACTS to + %TEMP%\TCL\ - the SAME copy-to-temp machinery as a direct-from-kit dll + load, so the TIP-741 non-cleanup/accumulation flaw applies equally (one temp dir + per binary, persists on exit; see G-103 Notes). Three loading locations all + converge on this one mechanism: (1) dll direct in a kit's zipfs, (2) standalone + .tm on disk, (3) .tm nested INSIDE a kit's zipfs - the nested (zip-in-zip) mount + works IN PLACE with NO pre-extraction of the .tm itself; only the dll load hits + temp. Note: LOADING a modpod .tm needs only zipfs (the stub is self-contained - + no punk/modpod package), so a single-name modpod .tm is plain-tclsh loadable. +- 2026-07-21 (user): MULTI-package-require-name modpod .tm (case variants like + Thread/thread, or sub-packages from one file) needs a manifest at a well-known + internal location discovered by libunknown during module scanning - NOT YET + IMPLEMENTED. Accepted consequence: a multi-name .tm is punkshell/libunknown-only, + NOT loadable in plain tclsh - fine PROVIDED the repo system/docs indicate this + clearly. TIP 590 ('recommend lowercase package names') makes the SINGLE-lowercase- + name path the happy case (plain-tclsh loadable, no libunknown, no Thread/thread + duplication) - the recommended shape for a downloadable single-file binary lib + when one require name suffices. New/complex mechanisms are acceptable in punkshell + IFF backed by extensive tests. Ties to G-035 (mixed .tm/pkgIndex discovery), + G-034 (modpod mount path), G-067 (punkbin publish of these artifacts). diff --git a/goals/G-067-module-artifact-channel.md b/goals/G-067-module-artifact-channel.md index 1eac3e72..d651e845 100644 --- a/goals/G-067-module-artifact-channel.md +++ b/goals/G-067-module-artifact-channel.md @@ -35,3 +35,10 @@ and pull (G-065) instead of re-vendoring by hand. - Related: G-006 (pattern source and candidate shared implementation), G-027 (remote infrastructure-pull transport candidate), G-065 (manifest integration), G-066 (artifact payloads and distribution-unit metadata). +- 2026-07-21 (user): binary-bearing zip-based .tm (modpod) are an intended publish + payload here - single-file downloadable libraries carrying manifest + binary + + script. Consuming-side load extracts the binary to %TEMP%\TCL* with the TIP-741 + non-cleanup flaw on windows (characterized - G-066/G-103 Notes). Single-lowercase- + name .tm (TIP 590) are plain-tclsh loadable; multi-require-name .tm need libunknown + (punkshell-only, must be documented). Generation + multi-name discovery detail: + G-066 Notes. diff --git a/goals/G-103-runtime-kit-family.md b/goals/G-103-runtime-kit-family.md index fc57e8e9..14c3d806 100644 --- a/goals/G-103-runtime-kit-family.md +++ b/goals/G-103-runtime-kit-family.md @@ -227,3 +227,8 @@ contract the sequencing note promises G-101. mapped, so the expectation there is NO accumulation; verify rather than assume. (Method: mount a zip containing a built dll, load from it, diff %TEMP%/tmpdir before+after and after exit; scratch scripts under the session scratchpad.) +- 2026-07-21: the modpod path was ALSO characterized on windows 9.0.5 - a binary + inside a zip-based .tm (self-mounting modpod, including one nested in a kit's + zipfs) extracts to %TEMP%\TCL* with the SAME non-cleanup flaw (details in G-066 + Notes). So windows = flaw confirmed for BOTH direct-kit and modpod-.tm binary + loads. Linux/WSL leg is blocked on a linux tcl9 runtime - see G-105 Notes. diff --git a/goals/G-105-buildsuite-cross-target.md b/goals/G-105-buildsuite-cross-target.md index 2f5c5a98..647809c9 100644 --- a/goals/G-105-buildsuite-cross-target.md +++ b/goals/G-105-buildsuite-cross-target.md @@ -54,3 +54,10 @@ dimension), G-102 (achieved 2026-07-21 - driver shape settled; target becomes a known wart (Tcl core TIP 741, windows-framed). Test on linux/WSL (and the G-060 guests) that it does not accumulate, or characterize it. TIP 741 detail + the cross-platform requirement: G-103 Notes. +- 2026-07-21: linux leg of the temp-cleanup characterization is BLOCKED on a linux + tcl9 runtime - the local WSL has only tcl 8.6.14 (no zipfs), so the zipfs + copy-to-temp path cannot be exercised there. Needs a linux tcl 9.0+ with zipfs + + a loadable .so (this goal's own cross-build, or an apt/self-built tcl9). Windows + is fully characterized (confirmed flaw, both direct-kit and modpod-.tm binary + loads - G-103/G-066 Notes); the linux expectation stays no-accumulation + (unlink-while-mapped) but is UNVERIFIED until a runtime exists.