winget duplicate package cant install

[JABirchall]

Checklist

• [X] I have read and understood the above text.

Describe the issue

There are 2 packages registered in winget with the same name, because of this bottom can not be updated or installed.

winget upgrade --query bottom                                                                                                                                      11/05/24 15:04:39
Multiple installed packages found matching input criteria. Please refine the input.
Name   Id
---------------------
bottom Clement.bottom
bottom Clement.bottom

[ClementTsang]

Hmmm... that's interesting, I only see one item here: https://github.com/microsoft/winget-pkgs/tree/master/manifests/c/Clement/bottom/0.9.6

Note that I don't use winget, so I don't know how to fix this exactly atm...

[ClementTsang]

Just making sure, is it not fixed by any of the suggestions here? https://github.com/microsoft/winget-cli/issues/282

[JABirchall]

Hmmm, i dont know if its a packaging issue or a winget issue. Locally there seems to be 2 bottoms, both have the same id and same case, so the -e didnt change anything. I also cant uninstall bottom to try fresh install it.

intrestingly there searching specifcally for Clement.bottom isnt working...

Ive installed the latest version via cargo instead, but the winget version is whats getting loaded when running btm so, Grrrrrrr.

[ClementTsang]

Hm, the fact that you can't uninstall it kinda makes me think it's a winget issue, but I can't confirm. The only thing I can think of that's possibly different about the bottom 0.9.6 package is that someone updated it after it was first initially added (https://github.com/microsoft/winget-pkgs/pull/118291), but that doesn't look like it changed anything significant given a quick look.

bottom in installed using an msi package when installed through winget so you might be able to find the program and uninstall it through control panel/settings? As for the potential duplicate entry in winget, if normal commands don't work I dunno if there's a way of forcefully uninstalling a program installed through it... I see some regedit solutions if I quickly look online but that's not exactly ideal.

[JABirchall]

Yep, there are 2 versions installs. 0.9.2 and 0.9.3 If something changed durring those versions on winget that prolly caused the issue.

I uninstalled 0.9.2 manually and am now able to upgrade to 0.9.6

Edit: After upgrading, i noticed it duplicated again I think you might be packaging wrong? Bottom doesnt replace the old version it just installs the new version in a new location?

[ClementTsang]

Hm, seems like from here I can apparently set upgradeBehavior: uninstallPrevious? I can look into that.

Apparently the default behaviour of winget is to just install versions side by side according to that issue. Seems like you hit the behaviour here: https://github.com/microsoft/winget-cli/issues/1865#issuecomment-1113106210

[JABirchall]

From what i can see, the install locations changed.

0.9.6 the install location is C:\Program Files\bottom\bin But i dont know where 0.9.3 is installed.

[ClementTsang]

Hm, I shouldn't have changed anything in between those versions off the top of my head.

[ClementTsang]

That said, I think I found a slight mistake in the way I'm using cargo wix which might cause some problems regarding update guid, gonna try and see if changing that fixes it.

[JABirchall]

Ok, did some investigations, 0.9.3 was also installed in C:\Program Files\bottom\bin but the registery of the version wasnt removed.

But yea, the issue is, the previous version isnt being unregistered from the users PC, breaking further updates/uninstall etc etc using winget.

[JABirchall]

That said, I think I found a slight mistake in the way I'm using cargo wix which might cause some problems regarding update guid, gonna try and see if changing that fixes it.

Yea that could be the issue, Im not sure how the GUIDs are ment to work, if its specific to the application or specific per version?

0.9.3 GUID is 2D38F097-BF34-4A73-AAD3-8B59BE42F03D 0.96 GUID is 85586C1B-BA83-48C2-84CC-A719227D22CF

I dont think you should do the "uninstall previous version" no other applications do that from what i can see, they just replace the files, I think that option is more for major version changes where you want to make sure all the old version files are removed before installing the new version.

[ClementTsang]

Yeah, so I think the problem is that when I build I would run cargo wix init each time, but I'm supposed to just run it once - because of that, it was regenerating upgrade-guid and path-guid each time, which I think causes the problem of it not detecting an upgrade.

I'm gonna fix that real quick and see if that works.

[JABirchall]

I just checked NuShell which i use and installed via winget, they dont uninstall the previous versions on install. https://github.com/microsoft/winget-pkgs/blob/master/manifests/n/Nushell/Nushell/0.93.0/Nushell.Nushell.installer.yaml

[JABirchall]

Yes, looks it the issue is that you init wix each time, checked nushell, and they havnt changed the GUID in 4 years. So looks like you need to keep the GUID the same.

https://github.com/nushell/nushell/blame/main/wix/main.wxs

and they dont init wix on build https://github.com/nushell/nushell/blob/main/.github/workflows/release-pkg.nu#L188-L200

[ClementTsang]

Cool, tested on a Windows VM that bumping the version will properly upgrade the existing binary.

Will make sure CI still works after changing that in the linked PR and merge in a bit. I think(?) I can try and patch the 0.9.6 binary + winget as well.