[Bug]: Can't shim ollama.exe: file doesn't exist

[wickles]

Prerequisites

• I have written a descriptive issue title.
• I have searched all issues/PRs to ensure it has not already been reported or fixed.
• I have verified that I am using the latest version of Scoop and corresponding bucket.

Package Name

ollama

Expected/Current Behaviour

Extraction of the setup file ends with multiple numbered binaries rather than the normal expected binaries, then fails during shim step because they names are different than expected.

Get-Command: ~\scoop\apps\scoop\current\lib\install.ps1:757
Line |
 757 |              $bin = (Get-Command $target).Source
     |                      ~~~~~~~~~~~~~~~~~~~
     | The term 'ollama.exe' is not recognized as a name of a cmdlet, function, script file, or executable program.
     | Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
Can't shim 'ollama.exe': File doesn't exist.

In ~/scoop/apps/ollama/0.3.12 I have these files

ollama app,1.exe
ollama app,2.exe
ollama,1.exe
ollama,2.exe

differing from the expected ollama app.exe and ollama.exe.

I ran the installer in a sandbox and found that the installed file names are not numbered like this after a regular install.

Steps to Reproduce

scoop update
scoop install ollama

Possible Solution

Could be a change in how the inno installer is configured, or some issue with the inno unpacker.

Scoop and Buckets Version

> scoop --version
Current Scoop version:
859d1db5 (HEAD -> master, tag: v0.5.2, origin/master, origin/HEAD) chore(release): Bump to version 0.5.2 (#6080)

'main' bucket:
5e4584e43 (HEAD -> master, origin/master, origin/HEAD) vault: Update to version 1.17.6

'extras' bucket:
9d436a36b (HEAD -> master, origin/master, origin/HEAD) snipaste: Update to version 2.10.2, fix checker (#14088)

'versions' bucket:
fc1cbc306 (HEAD -> master, origin/master, origin/HEAD) zig-dev: Update to version 0.14.0-dev.1655

'java' bucket:
c2cc31cd (HEAD -> master, origin/master, origin/HEAD) temurin8-nightly-jre: Update to version 8.0.432-4.0.202409241124

'games' bucket:
36991cdd6 (HEAD -> master, origin/master, origin/HEAD) wemod: Update to version 9.10.3

Scoop Config

> scoop config

last_update           : 9/25/2024 8:04:11 PM
aria2-warning-enabled : False
scoop_branch          : master
scoop_repo            : https://github.com/ScoopInstaller/Scoop
alias                 :
use_sqlite_cache      : True

PowerShell Version

> $PSVersionTable

Name                           Value
----                           -----
PSVersion                      7.4.5
PSEdition                      Core
GitCommitId                    7.4.5
OS                             Microsoft Windows 10.0.22631
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Additional Softwares

> scoop list inno
Installed apps matching 'inno':

Name            Version Source   Updated             Info
----            ------- ------   -------             ----
innounp-unicode 1.72    versions 2024-07-30 19:42:47

[wickles]

Assuming this is not just a local problem on my computer -- it would be nice if the excavator could do some basic validation before checking in random updates that could easily break packages if the archive layout changed. Of course it would also be nice if this did not require additional VM resources.

[ubranch]

[infomaniac50]

Ollama is now packaging ARM builds alongside x64. https://github.com/ollama/ollama/releases/tag/v0.3.12

If I try to run ollama app,2.exe, then Windows says "This app can't run on your PC" but ollama app,1.exe runs normally. There are other files with the same naming patterns in lib\ollama\runners\cpu. If there is a way to see the architecture of the executables then they could be matched with the machine scoop is running on and renamed appropriately. The install script also lists these files and does checks for which architecture is in use.

[boltomli]

Uniextract2 handles the files with correct arch after extraction. Have to replace the bundled innounp.exe with innounp unicode though. I manually created 0.3.12 folder this way and it works.

[Wuming-HUST]

I encountered the same issue. But I install 2 version of innounp.

❯ scoop list inno
Installed apps matching 'inno':

Name            Version Source   Updated             Info
----            ------- ------   -------             ----
innounp         0.50    main     2022-02-20 09:43:20
innounp-unicode 1.72    versions 2024-08-15 04:13:57

[otavio-silva]

I have the same issue, and I'm using innounp-unicode only:

scoop list inno
Installed apps matching 'inno':

Name            Version Source   Updated             Info
----            ------- ------   -------             ----
innounp-unicode 1.72    versions 2024-07-30 20:25:12