Add "Ignore installed package" option

[SiJiL82]

There are several packages that have been added by the community that are problematic / just incorrect, which prevents you from doing an "upgrade all".
It would be very useful to have an "ignore" option where you can specify an installed program to just exclude from the winget upgrade functionality.

For example:

Name Id Version Available Source

Unity UnityTechnologies.Unity 2020.3.16f1 2021.1.19f1 winget

Unity 2021 is not an upgrade from 2020 - it is a completely separate application, and the manifest for it should not have been created like this. Rather than have it permanently there every time I do an upgrade search, it would be much better to be able to just never see it.

Obviously it would be better to not have these problematic packages in the first place, but there doesn't currently seem to be an effective way to get them removed / fixed.

[siddagra]

Agreed. I proposed a similar issue but I think a better way to fix this may be to just state the errors and move on to upgrading the next package instead of failing the entire upgrade sequence. I mention this here: #1442

[jedieaston]

We've had the discussion about Unity before. The problem is that we want to have multiple versions of Unity in the repo, so that people can just install what they want via --version, but then winget upgrade makes a mess of things.

#476 is the standing solution to the problem, and I guess it's on the backlog for the next major release after 1.1 (I have absolutely no idea when that is though, since 1.1 hasn't had any public builds yet).

[saxc]

I would also prefer an ignore list. I have several cases in which I want to use this.

Here are two examples.

• The GOG GALAXY installed version shows me as Unknown. One each upgrade --all it downloads the file and starts the installer, the installer shows the message that this or a newer version is installed.

• By an Visual Studio Update i prefer the Visual Studio installer to install the Update.

[denelon]

@jedieaston the release yesterday https://github.com/microsoft/winget-cli/releases/tag/v1.0.12576 has most of the work for Windows Package Manager v1.1 we're doing some additional internal testing and a few more tweaks. It's very close [tm].

[robross0606]

Obviously it would be better to not have these problematic packages in the first place, but there doesn't currently seem to be an effective way to get them removed / fixed.

To me, this is the crux of the problem. Firstly, winget relies on one set of information to determine what is available to install. Then it relies on a completely separate set of information (outside its control) for upgrade information. This is a fragile system at the design level that is bound to have problems.

Redesigning the system notwithstanding, if winget relies on critical data being in the installer package, there needs to be a formal way to report issues with published installers in the ecosystem that results in two things:

1. Microsoft reports the non-complaint package to the developer.
2. Microsoft removes the non-compliant package from the winget ecosystem until a complaint one is resubmitted from the developer.

What should not happen is redirecting individual users to plead directly with developers so Microsoft can get their own fragile ecosystem functional again.

[denelon]

@robross0606 we are working on that part of the ecosystem. The Microsoft Store builds the business relationships with publishers which is why that is the preferred mechanism as mentioned in the Windows Package Manager 1.1 blog. In the community repository, it's a bit less formal. We certainly would prefer to have publishers become "verified" so we have those lines of communications.

Note: We're still working on the business process for identifying "verified" developers in the Windows Package Manager Community App Repository.

[robross0606]

In the community repository, it's a bit less formal.

What if winget users could configure which repositories it used?

This would be quite similar to how apt or other package managers work in that there would be "verified" and "community" repositories. Make users opt-in on less stable packages if they want. This would be a bit of a safety valve while you hash out your business relationships with vendors, as well as a way to indicate to users that they can expect a bumpy road.

[Masamune3210]

Winget aleady has support for multiple user configured repos, just no other official ones exist currently other than the main one and msstore

[denelon]

We have that work in progress as well. The current biggest gap is:

• Configure Behaviors for multiple sources #1488.

Users can currently add or remove sources (Group Policy permitting). The default sources are currently the Microsoft Store "msstore" source, and the Windows Package Manager Community App Repository "winget" source. We're making some improvements to the "msstore" source so that will likely be the default preferred source once the work is completed. The feature mentioned above will allow users (and IT administrators) to configure the default behaviors.

[jdhitsolutions]

This idea of ignoring packages isn't always tied to a repo. This is one example.

I manually installed this app, yet winget detects it. There really is no upgrade. v1.5.1 is it. It would be helpful that have a way to suppress this item.

[SiJiL82]

The ideal solution to that though is to get in contact with the developer and ask them to update their installer so it reports the version correctly. Then it'll work with winget as expected.

[jdhitsolutions]

The problem is that this is a legacy app. Unfortunately, Winget detects and reports on all applications, even those installed manually. So either Winget needs a way to only report on apps installed with Winget or a suppression mechanism.

[jedieaston]

Thoughts on #1692 (comment) as a solution? It's kind of the opposite way of going about things (explicitly saying upgrade apps with no known version number instead of ignoring certain ones), but will work as a stopgap until pinning is available for more control.

[jdhitsolutions]

That would certainly be a better solution than what we have now.

[fluentmoheshwar]

I also need this,

[magic280z]

Add to this something like Citrix Workspace is wrong 19.12.3000.6 is LTSR it should upgrade to 19.12.6000.x not 22.2.0.4525. Looks like the same thing for Office 365. Update channel needs to be supported. Until then exclusions and manually handling of excluded items better.

                        Citrix.Workspace                  19.12.3000.6     22.2.0.4525      winget

[chbwien]

E.g. Irfanview does everything correct. But companies get special versions with the same version number. Winget does not see the difference and will upgrade with the public version.... So there are reasons to suppress upgrades for some packages. This also might be a license restriction (e.g. updates are only within the license for one year, every update after that breaks the app)!

[denelon]

@chbwien you should probably also take a look at:

• Pin a package #476

as well.

I wasn't aware of this specific scenario. I would hope there would be some metadata differences that would allow us to distinguish between these different versions of a package, but now I understand. Thanks so much for providing the explicit scenario here. Do you know of any specific applications that exhibit this behavior? I'd love to have a test case.