a no-interaction mode, for people who want to use the script in automations
an automatic dependency installation mode, for people who want to use the script to create docker images
the possibility of packaging an installer script into the tarball, in the linux case
representing system dependencies in a separate file that the script references and that the docs can also reference to report system dependencies, so that they are in one place and never go out of sync
macOS stable extension issues
Signs point to a stale state during our attempt to do an incremental rebuild on the macOS factory machine. Ebrahim will disable nightly and do a completely clean rebuild of both SLicer and extensions on the macOS factory machine. This will have to be called 5.12.2 even though there might not be any actual changes, so that there is not a chance of confusing two different 5.12.1 packages. Planning to kick this off tomorrow.
@muratmaga Hopefully 5.12.2 does not have the extensions issue on macOS, but I have not tried it. Please let us know if, when you try it, the same issue still occurs. Our testing strongly suggested that a clean re-build should fix things but there was not certainty.
@ebrahim I observed errors upon launching Slicer 5.12.2 with the MarkupsToModel extension with the message appearing to mention “relative path not allowed in hardened program” where the hardened program is likely tied to the fact that Slicer stable releases (unlike Preview builds) are codesigned and notarized. I’m using macOS Tahoe for reference here.
A few governance questions I cannot answer myself:
When the target version is already installed and you haven’t set SLICER_IF_EXISTING env variable, what should a no-interaction run do: reinstall it (today’s no-terminal behavior) or exit 0 without touching it? This is the idempotency question — it decides whether repeated automation runs re-download ~1 GB or become no-ops.
Do you also need quiet output (no logo, no progress bar) for logs, or is suppressing prompts enough?(default: prompts only — logo and progress bars are already suppressed when output isn’t a terminal)
Linux/macOS only, or do you automate the Windows installer too?
If installing dependencies fails, should the whole install fail (good for RUN steps in a Dockerfile) or warn and continue?
If the script is not root, should it attempt sudo (which may password-prompt — colliding with no-interaction mode) or refuse and print the command as it does today?
Do you run Slicer headless in the container (e.g. xvfb-run Slicer --no-main-window)? If so, should the mode optionally install headless extras like xvfb, or stay strictly at Slicer’s runtime library list?
Who is it for: people who manually download the tarball from download.slicer.org and want the wiring (launcher symlink, menu entry, deps hint) afterwards, or is the goal to get upstream Slicer packaging to bundle the script officially?
When run from an extracted tree, should it wire that tree up in place (wherever it was extracted), move it to the standard ~/.local/opt location, or ask?
Should it be the same install.sh gaining an offline/local mode (one file, could be dropped into the tarball as-is), or a separate minimal script that contains only the wiring logic?
Must it work fully offline (no checksum/version lookups at all)?
Should it also offer uninstall of that copy?(default: yes — the uninstall logic already exists in uninstall_linux)
Who consumes the file besides this repo’s README — e.g. the official Slicer docs or a Discourse post wanting a stable URL? Decides whether the file format/location becomes a public contract.
Plain text lists per package manager (deps/apt.txt, deps/dnf.txt, deps/pacman.txt) or something structured (JSON/YAML) for machine consumption?
Is a repo-internal sync acceptable — the lists get embedded into install.sh by a generator, with a CI check that fails on drift — or do you want the script to fetch the file at runtime so even old script copies stay current? Runtime fetching adds a network failure mode to curl | sh; embedding keeps the script self-contained.
Should the file format express conditionals (e.g. libasound2t64 vs libasound2 depending on Ubuntu release), or does that logic stay in the script with the file listing the canonical names?
@mau_igna_06 Thanks for making this script and working out the questions that we need to answer. Maybe a first step could be to create the draft PR with the current script and start the discussion there (copying some of these same questions there). So that way everyone can see the script and comment on it, try things out in the context of building the docs, etc.
This post was written with AI assistance.
