After winget upgrade ImageMagick.ImageMagick, two different versions are installed side-by-side

[sba923]

Brief description of your issue

On a system with ImageMagick version 7.1.0.62, I ran winget upgrade ImageMagick.ImageMagick.

Now I have both versions 7.1.0.62 and 7.1.1.3 installed side-by-side (both machine-scope).

Steps to reproduce

Run winget upgrade ImageMagick.ImageMagick on a system with ImageMagick version 7.1.0.62 installed.

Expected behavior

ImageMagick version 7.1.0.62 should've been replaced by the latest version (7.1.1.3).

Actual behavior

Both versions 7.1.0.62 and 7.1.1.3 are installed side-by-side (both machine-scope), in C:\Program Files\ImageMagick-7.1.0-Q16-HDRI and C:\Program Files\ImageMagick-7.1.1-Q16-HDRI, respectively.

Environment

Windows Package Manager v1.4.10173
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.19045.2604
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.19.10173.0

Logs: %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir

User Settings: %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\settings.json

Links
---------------------------------------------------------------------------
Privacy Statement   https://aka.ms/winget-privacy
License Agreement   https://aka.ms/winget-license
Third Party Notices https://aka.ms/winget-3rdPartyNotice
Homepage            https://aka.ms/winget
Windows Store Terms https://www.microsoft.com/en-us/storedocs/terms-of-sale

[denelon]

This is often the case with packages that install side-by-side rather than upgrade over a range of versions.

In recent versions of the client, we've added "--uninstall-previous", and it's possible to add the same logical behavior to the manifest.

[sba923]

So this is a package issue (thought it could be), that I have posted in the wrong project? Sorry for that...

[sba923]

Note that the situation after this upgrade which is not an upgrade is weird, 'cos you have two products with the same ID, but two different (truncated...) names:

What's the "proper way" to uninstall the older of the two versions--using the winget client, of course--?

[denelon]

@sba923 the entire class of "Side-by-Side" issues is tricky. We don't always know which "newer" versions of packages are going to be an "in place upgrade" vs. a new "side by side" install. Unfortunately, not everyone follows semantic versioning (including Microsoft) for every package.

There is likely additional work needed in the schema, the client, and subsequently manifests. We've been chipping away at it, but it's also hard to set the right expectations for users when WinGet doesn't have enough information to be able to determine exactly what is going to happen.

We have a long tail of work to do related to testing the upgrade scenario on the most recent previous version of packages. Creating these issues will still help others find them and as we continue to make improvements, it should help users reason about what is happening, and what they want to have happen on their system.

[denelon]

The "separate" package "displayName" values are coming from the installer. In the community repository, the package identifier is "ImageMagick.ImageMagick", but those two versions are "side-by-side".

The community hasn't modified the manifest to have "uninstallPrevoius" either because it hasn't been reported, or because user settings might be lost of the previous version is uninstalled before the new one gets installed. The same thing happens with "Ultimaker.Cura" and several other packages.

[denelon]

Given the very "long" name, it's hard to capture via cli without making the terminal width wide enough to display it all. Optionally, the PowerShell cmdlet could be used to capture the full name, or you could use Windows Apps & Features to uninstall.

Lots of paper cuts we need to continue working on here...

[sba923]

My terminal window was wide enough:

[sba923]

I must confess I have kinda paused experimenting with the PowerShell cmdlets due to the issues I considered blocking (mainly with piping e.g. into Where-Object IIRC)

[denelon]

No worries 😊

[sba923]

No worries 😊

so I didn't miss a recent key improvement in the cmdlets, did I?

[denelon]

February 14th, 2023 is the latest release which had some fixes.

[sba923]

But apparently this still doesn't work:

but this is not the place to discuss this 😜

[sba923]

My terminal window was wide enough:

Is there an existing issue for this?

[denelon]

My terminal window was wide enough:

Is there an existing issue for this?

• Increasing terminal width doesn't address truncation #3071

[ryfu-msft]

But apparently this still doesn't work:

but this is not the place to discuss this 😜

We don't have a property for 'available'. The property name might have changed since you last used it. You should use 'AvailableVersions' instead:

get-wingetpackage | ? { $_.AvailableVersions -ne '' }

[sba923]

Let's continue here: #2796 (reply in thread)

[vborovikov]

In recent versions of the client, we've added "--uninstall-previous", and it's possible to add the same logical behavior to the manifest.

What version of winget support this flag?

[denelon]

It's an experimental feature in the latest preview.

[denelon]

Is this still happening on WinGet 1.8?

[sba923]

I haven't experienced this in quite a while, so the answer seems to be "no."

Most recent version is dated 2024-06-23, let's confirm at the next update?

[sba923]

Haven't experienced this in quite a while, so the answer seems to be "no."

Most recent version is dated 2024-06-23, let's confirm at the next update?