I cannot update the package built using inno setup

[MesterPerfect]

I cannot update the package built using inno setup

[mdanish-kh]

WingetCreate uses the architecture field (along with others if present) to find a suitable installer match for update from the previous manifest. When it cannot determine the architecture of the new installer from the URL (it looks for specific keywords like x64, x86, 32-bit etc), it tries to scan the installer binary to determine its arch.

It's known that Inno is an x86 application, so inno installers are usually x86 irrespective of the architecture of the application it installs. What's happening here is that since the previous / base manifest contains a single installer node of x64 arch, WingetCreate tries to find a new URL from the command you've written that can match this installer node in the update. It cannot determine the arch from URL, so falls back to using binary architecture which happens to be x86 and due to this arch mismatch, WingetCreate fails to update the package.

An easy fix here is you can override this behavior and explicitly tell WingetCreate what architecture you would like to target by appending it at the end of the URL. You can use this command to update your package:

wingetcreate update tecwindow.SoundTranscriber --version 1.3.0 --urls "https://github.com/tecwindow/SoundTranscriber/releases/download/V1.3.0/SoundTranscriberV1.3.0.exe|x64"

[MesterPerfect]

WingetCreate uses the architecture field (along with others if present) to find a suitable installer match for update from the previous manifest. When it cannot determine the architecture of the new installer from the URL (it looks for specific keywords like x64, x86, 32-bit etc), it tries to scan the installer binary to determine its arch.

It's known that Inno is an x86 application, so inno installers are usually x86 irrespective of the architecture of the application it installs. What's happening here is that since the previous / base manifest contains a single installer node of x64 arch, WingetCreate tries to find a new URL from the command you've written that can match this installer node in the update. It cannot determine the arch from URL, so falls back to using binary architecture which happens to be x86 and due to this arch mismatch, WingetCreate fails to update the package.

An easy fix here is you can override this behavior and explicitly tell WingetCreate what architecture you would like to target by appending it at the end of the URL. You can use this command to update your package:

wingetcreate update tecwindow.SoundTranscriber --version 1.3.0 --urls "https://github.com/tecwindow/SoundTranscriber/releases/download/V1.3.0/SoundTranscriberV1.3.0.exe|x64"

This indeed works. The manifest files have been successfully downloaded and updated. Thank you for your assistance.

I hesitated to open issues for something as straightforward as this, but the winget docs lack clear examples or documentation for such issues. They also do not specify the correct way to write commands.

There's one more thing: I submitted pull requests to winget three days ago or more, and they haven't been approved yet. Is this normal?

[ryfu-msft]

WingetCreate uses the architecture field (along with others if present) to find a suitable installer match for update from the previous manifest. When it cannot determine the architecture of the new installer from the URL (it looks for specific keywords like x64, x86, 32-bit etc), it tries to scan the installer binary to determine its arch.
It's known that Inno is an x86 application, so inno installers are usually x86 irrespective of the architecture of the application it installs. What's happening here is that since the previous / base manifest contains a single installer node of x64 arch, WingetCreate tries to find a new URL from the command you've written that can match this installer node in the update. It cannot determine the arch from URL, so falls back to using binary architecture which happens to be x86 and due to this arch mismatch, WingetCreate fails to update the package.
An easy fix here is you can override this behavior and explicitly tell WingetCreate what architecture you would like to target by appending it at the end of the URL. You can use this command to update your package:

wingetcreate update tecwindow.SoundTranscriber --version 1.3.0 --urls "https://github.com/tecwindow/SoundTranscriber/releases/download/V1.3.0/SoundTranscriberV1.3.0.exe|x64"

This indeed works. The manifest files have been successfully downloaded and updated. Thank you for your assistance.

I hesitated to open issues for something as straightforward as this, but the winget docs lack clear examples or documentation for such issues. They also do not specify the correct way to write commands.

There's one more thing: I submitted pull requests to winget three days ago or more, and they haven't been approved yet. Is this normal?

Thanks for calling this out, we need to work on updating the docs to make it more clear on what the best course of action is if these errors are encountered.

Regarding your PR, it should have been checked in or at least reviewed. It takes a couple hours to go through our validation pipeline and a couple days for one of our moderators to approve it (Maybe a bit more given the timing of the holidays 🦃 ). Any errors that appear or feedback from our moderators need to be address before your manifests get checked in.

[MesterPerfect]

Regarding your PR, it should have been checked in or at least reviewed. It takes a couple hours to go through our validation pipeline and a couple days for one of our moderators to approve it (Maybe a bit more given the timing of the holidays 🦃 ). Any errors that appear or feedback from our moderators need to be address before your manifests get checked in.

ChatGPT
"This topic is frustrating for me. Some programs submitted just minutes ago, like this one:

microsoft/winget-pkgs#129129

were immediately approved. Meanwhile, my program, launched three days ago, has yet to receive approval:

microsoft/winget-pkgs#128834

What mechanism is being relied upon in this process?"

[Masamune3210]

It was accepted 2 hours ago....

[MesterPerfect]

It was accepted 2 hours ago....

"Yes, my program was approved immediately after being mentioned here."

[Trenly]

@MesterPerfect; The community moderators over at winget-pkgs are all volunteers. Often times we, like the MSFT engineers, get busy with family or friends on the weekends, or have limited amout of time throughout the day to do reviews - sometimes its 20 minutes here, 30 minutes there, 15 minutes between other things going on, its not always an hour or two of concentrated time. A common practice is to start with the "easy" reviews or the PRs related to well-known packages and then work through the ones that remain. This is why some packages take only a few hours to be reviewed (Chrome, Firefox, and Git, for example, all make it past my email filter) and others take longer. Add onto that the fact that some packages need a MSFT employee to look at them and add a waiver, it all adds up quickly.

---

Specific to your PR, I see a few reasons why it took 3 days to be reviewed -

1. It was submitted on Friday, and many moderators have limited availability on weekends
2. It is not for a well known package which is relied upon by many users
3. The PR history isn't clean; There was the unattended install issue, and 3 commits that don’t have descriptive messages. This means that a moderator needs to spend more time checking the install and verifying the content. One suggestion would be to use commit messages like "Fixed Installer Architecture" or "Updated Dependencies" to make it easier to understand why the changes fixed the issues and gives confidence that they won’t re-appear in unique environments.