[investigate] Segger: clarify version 1.0.14 source — dongzehe/segger container vs upstream dpeerlab/segger (canonical) / EliHei2/segger_dev (legacy)

Current state

• Pinned: container quay.io/dongzehe/segger:1.0.14 at modules/local/segger/create_dataset/main.nf:6
• Modules: segger/create_dataset, segger/train, segger/predict
• Pipeline modes: coordinate (when --method segger)

Canonical upstream — two candidate repos

The README migration notice on EliHei2/segger_dev confirms dpeerlab/segger (Dana Pe'er lab at MSKCC — segger's institutional home) is the current canonical repo. EliHei2 is the prior maintainer (a contributor) who has handed maintenance back to the lab.

Neither repo has formal release tags as of audit time.

The version mismatch

• Pipeline pins 1.0.14
• Neither upstream has any release tagged 1.0.14
• Container is owned by dongzehe (Genentech-affiliated) — likely a custom / internal build, source provenance unclear
• Result: the pinned container is not traceable to any upstream release tag of either repo

Investigation questions

• What commit (and from which repo: dpeerlab/segger or EliHei2/segger_dev) does quay.io/dongzehe/segger:1.0.14 correspond to?
• Should the pipeline be tracking dpeerlab/segger (the canonical successor) directly?
• Is there a Wave / nf-core / dpeerlab-published container we should use instead of quay.io/dongzehe/segger?

Risks

• Supply chain: pinning to a non-upstream-traceable container is a meaningful risk for a public nf-core pipeline. Users and reviewers cannot independently verify what code runs.
• Reproducibility: if quay.io/dongzehe/segger:1.0.14 is ever deleted or rebuilt, behavior may change silently.
• Wrong-repo risk: if the dongzehe container was built from EliHei2/segger_dev (now-legacy), the pipeline is running stale code while the canonical maintenance is on dpeerlab/segger.

Migration plan

• Open an issue at dpeerlab/segger requesting tagged stable releases + an official container build
• Switch to a dpeerlab/segger-derived container as soon as one is available
• Document the version provenance prominently in modules/local/segger/*/meta.yml

Cross-links

• Triggered by: Atera compatibility evaluation session 2026-05-28 (broader tool inventory check).

Start with modules/local/segger/create_dataset/main.nf and the segger module directories, then inspect the provenance of quay.io/dongzehe/segger:1.0.14 against dpeerlab/segger and EliHei2/segger_dev. Determine the source commit and an appropriate canonical container or release path; the work is done when the container choice is traceable and provenance is documented in modules/local/segger/*/meta.yml.