github-starred/ollama
2
0
Fork 0
mirror of https://github.com/ollama/ollama.git synced 2026-05-24 06:31:50 -05:00
Code Issues 16.9k Packages Projects Releases 122 Wiki Activity

[PR #10846] scripts: Check existing version in Linux install script #44635

New Issue
Open
opened 2026-04-25 00:14:38 -05:00 by GiteaMirror · 0 comments
GiteaMirror commented 2026-04-25 00:14:38 -05:00
Owner
Copy Link

📋 Pull Request Information

Original PR: https://github.com/ollama/ollama/pull/10846
Author: @philippgille
Created: 5/24/2025
Status: 🔄 Open

Base: main ← Head: check-existing-version-in-linux-install-script

📝 Commits (2)

  • fec4d03 Check existing version in Linux install script
  • 9b5317e Mention --force flag in Linux installation docs

📊 Changes

2 files changed (+35 additions, -3 deletions)

View changed files

📝 docs/linux.md (+3 -1)
📝 scripts/install.sh (+32 -2)

📄 Description

As requested in #8233, this PR adds a check for an existing Ollama installation to the Linux install script. In detail:

  • If --force is passed as flag, the check is skipped
  • If OLLAMA_VERSION env var is set, the script checks the installed version for equality with that version. If they're equal, the script exits
    • Why check for equality and not "is equal or newer" by semver rules? => If someone sets a version with OLLAMA_VERSION, they might want to downgrade on purpose. For example here some people initially downgraded to v0.5.7 due to some issues.
  • If the env var is not set, the latest version is determined via GitHub API (latest release), and the script checks that against the installed version. Also equality is used.
    • Why check for equality and not "is equal or newer" by semver rules? => For example if you release v0.8.0 and mark it as latest release on the GitHub release page, then notice a security issue, and then go to v0.7.1 and mark that as latest. Then you want people who run the script to install v0.7.1, even if they previously installed v0.8.0 already.

The "latest release" feature on GitHub also helps with another thing: If the current release is v0.7.1, then you release v0.8.0 with various breaking changes, and then someone reports a security issue in v0.7.1, but you don't want people to force through the breaking changes yet. You can release a v0.7.2 with the security fixes, but not mark it as "latest release" on GitHub, even if from a chronological PoV it was released later. The /releases/latest GitHub API endpoint will continue to return v0.8.0.

With "mark as latest release" I mean this checkbox on a GitHub release page:
image

Fixes #8233

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/ollama/ollama/pull/10846 **Author:** [@philippgille](https://github.com/philippgille) **Created:** 5/24/2025 **Status:** 🔄 Open **Base:** `main` ← **Head:** `check-existing-version-in-linux-install-script` --- ### 📝 Commits (2) - [`fec4d03`](https://github.com/ollama/ollama/commit/fec4d037021aa0b9db704537f77bf136d730c557) Check existing version in Linux install script - [`9b5317e`](https://github.com/ollama/ollama/commit/9b5317e11ad77db1b2f1c05bbcde52d227b78e91) Mention --force flag in Linux installation docs ### 📊 Changes **2 files changed** (+35 additions, -3 deletions) <details> <summary>View changed files</summary> 📝 `docs/linux.md` (+3 -1) 📝 `scripts/install.sh` (+32 -2) </details> ### 📄 Description As requested in #8233, this PR adds a check for an existing Ollama installation to the Linux install script. In detail: - If `--force` is passed as flag, the check is skipped - If `OLLAMA_VERSION` env var is set, the script checks the installed version for *equality* with that version. If they're equal, the script exits - Why check for equality and not "is equal or newer" by [semver](https://semver.org/) rules? => If someone sets a version with `OLLAMA_VERSION`, they might want to downgrade on purpose. For example [here](https://github.com/ollama/ollama/issues/9503) some people initially downgraded to v0.5.7 due to some issues. - If the env var is not set, the latest version is determined via GitHub API (latest release), and the script checks *that* against the installed version. Also *equality* is used. - Why check for equality and not "is equal or newer" by [semver](https://semver.org/) rules? => For example if you release v0.8.0 and mark it as latest release on the GitHub release page, then notice a security issue, and then go to v0.7.1 and mark that as latest. Then you want people who run the script to install v0.7.1, even if they previously installed v0.8.0 already. The "latest release" feature on GitHub also helps with another thing: If the current release is v0.7.1, then you release v0.8.0 with various breaking changes, and then someone reports a security issue in v0.7.1, but you don't want people to force through the breaking changes yet. You can release a v0.7.2 with the security fixes, but not mark it as "latest release" on GitHub, even if from a chronological PoV it was released later. The `/releases/latest` GitHub API endpoint will continue to return v0.8.0. With "mark as latest release" I mean this checkbox on a GitHub release page: ![image](https://github.com/user-attachments/assets/a8e6f904-4008-4b10-8b7e-8057e79eef9f) --- Fixes #8233 --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
GiteaMirror added the pull-request label 2026-04-25 00:14:38 -05:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
amd
api
app
bug
build
cli
cloud
compatibility
context-length
create
docker
documentation
embeddings
feature request
feedback wanted
good first issue
gpt-oss
gpu
harmony
help wanted
image
install
intel
js
launch
linux
macos
memory
mlx
model
needs more info
networking
nvidia
ollama.com
performance
pull-request
Mirrored from GitHub Pull Request
 python
question
registry
rendering
thinking
tools
top
vulkan
windows
wsl
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/ollama#44635
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?