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

[an-altosian]

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

Repo	Last push	Latest commit	Stars / Forks	Status
https://github.com/dpeerlab/segger	2026-05-27	2026-05-26 "[main] Integration/peerlab (#38)"	17 / 8	Active development, canonical successor
https://github.com/EliHei2/segger_dev	2026-05-25	2026-03-11 "Update README with migration notice for new version"	90 / 13	Legacy — README migrated users to the new repo

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).