-
Notifications
You must be signed in to change notification settings - Fork 85
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow updating a manifest with a different number of installer URLs #291
Comments
@FayneAldan - Just an FYI; PolyMC actually has a bot that submits their releases automatically microsoft/winget-pkgs#67332 |
Yes, I am aware. I tried to update the package manually after Winget Releaser picked the wrong installers, but Winget Create wouldn't let me do it. |
Hey @FayneAldan, We actually do support your scenario. The reason why it didn't work is because the manifest of the latest version of PolyMC (v1.4) only has one installer URL which has already been checked in. We always use the latest version for the update. If that manifest wasn't checked in, you could have done something like this:
Winget-Create already has logic to help match the installers with the correct architecture but if you find that it didn't match it correctly, you can also override the detected architecture:
Just fyi, in case you ever try this again in the future :) |
Well, I'm also getting this error but with manifests that have two entries for the SAME installer/architecture, due to scope
This used to work, so it's a recent issue. |
NB, same error with two scopes and one installer is mentioned back in 2021 here: microsoft/winget-pkgs#500 (comment). The version of winget-create I was using was even older, I think, and I only recently updated to the latest version, hitting this error each time I try to update that and similar manifests for my apps. I've been having to calculate the SHAs using PowerShell and update manifests manually, though I'll give https://github.com/vedantmgoyal2009/winget-releaser a go. |
@ryfu-mfst Thanks for picking this up. Just to note, that in my case it's not different architectures that are causing the winget-create issue, it is different installer scopes: Scope: user and Scope: machine. The architecture is the same in both cases (x86).
… @Jaifroid, thanks for bringing this to my attention. Looks like this is a bug that I will need to fix to address the scenario where the same installerURL is being used for multiple architectures. Will work on a fix for this...
|
Same issue here. Workaround that maybe can work is to pass the |
I have the same issue. Related to #166 IMO |
The thing is, this used to work before September 2021, then an update broke it. Whichever dev is working on wingetcreate, I think this needs to be a priority. One of the main reasons to use wingetcreate is in automated build and publishing, but it's currently causing me to have to intervene manually (in a laborious way) each time I prepare a new release. I'm about to give up and just write an automated powershell script to grab the SHA and forcibly update the mainfest values, but this won't do any of the testing and validation that is a great benefit of wingetcreate. |
Is there any update on allowing wingetcreate to update manifests that have the same package listed for different scopes (per user and per machine)? It's currently unusable, as it errors out, saying that a manifest shouldn't have the same package listed twice. This is clearly a bug, because we don't need different packages for different scopes. Usually it's just a quesiton of changing an installer flag on the commandline. This used to work in wingetcreate, before September 2021. It should be an easy fix. |
I'm having the same problem trying to update the package "TheDocumentFoundation.LibreOffice.HelpPack" to a new version and adding installers for other locales. |
Having the same problem reported above by @Jaifroid updating the package |
cc @denelon Resolved in WinGet-Create 1.2.6.0 |
@mdanish-kh @denelon Thanks for the update and the advice to use overrides. I've now tested this, and although the overrides work, I do not consider this issue to be fully fixed for my use case. Wingetcreate, with overrides for per user and per machine on the same bundle or executable, downloads the exact same file twice. Since I am frequently (at least twice a month) validating and submitting manifests for executables of 1GB and 1.6GB, this is very unfortunate, and definitely not necessary. Wingetcreate should check the URL, and not process identical URLs twice, as it has already worked out the hash. The commandline I'm useing is:
The If you think it's best to open a new issue, I'll be happy to do so. |
I don't think the issue is really resolved. It's still impossible to add or remove an installer option using |
@stevapple The original issue was more related to the fact that the PR creation failed even when matching the number of URLs in the previous manifest Your request is being partially tracked in #351 (request for an option like |
@mdanish-kh Thanks for pointing out! Maybe this issue can have a new title to more accurately reflect the status quo? |
Description of the new feature / enhancement
Hello. I'm trying to update a package (
PolyMC.PolyMC
) that has stopped distributing 64-bit exes and I can't update the manifest because of this error:This error should be a warning instead, prompting the user if they want to continue anyways.
Proposed technical implementation details
No response
The text was updated successfully, but these errors were encountered: