search

microsoft / winget-cli

WinGet is the Windows Package Manager. This project includes a CLI (Command Line Interface), PowerShell modules, and a COM (Component Object Model) API (Application Programming Interface).
https://learn.microsoft.com/windows/package-manager/
MIT License
22.97k stars 1.43k forks source link

Remove support for Neutral architecture #1981

Open Trenly opened 2 years ago

Trenly commented 2 years ago

Description of the new feature / enhancement

Related to #1980 This would be a breaking change

With tools for creating multimanifests being well established, the ability to add multiple installer nodes is fairly trivial. As the client becomes smarter in terms of determining supported architectures and mapping packages to a users preferred or required architecture, the removal of neutral would force package metadata to be more complete.

Proposed technical implementation details

In the case of a neutral installer, an installer node for each architecture could be used instead.

Alternatively, Architecture could be changed to an array type. This (personally) would make the most sense, as it would align with the concept of Supported Architectures and UnsupportedArchitectures (#993)

jedieaston commented 2 years ago

The array type for architectures would (IMO) be required for this. Duplicating installer nodes for every architecture when they all use the same installer (and options) would be super annoying.

Jaifroid commented 2 years ago

I use appxbundles which support any architecture on which Windows 10/11 can run. It would be annoying for winget to require me to specify an architecture: this would be subverting an important feature of such app packages for no particularly good reason that I can see.

jedieaston commented 2 years ago

That brings up a good point. Wasn't neutral made specifically for appxbundles?

denelon commented 2 years ago

Having the supported architectures specified in the manifest prevents us from having to download the package to see if it is compatible with the architecture of the system. It would also prevent us from properly being able to honor a "requirement" setting for a specific architecture if that architecture isn't explicitly available.

I'm talking with the team about this to see what makes the most sense.

Trenly commented 2 years ago

That brings up a good point. Wasn't neutral made specifically for appxbundles?

I think that in cases where an installer truly is neutral, then it would be able to be specified for all the installer architectures individually. Wingetcreate and YamlCreate should easily be able to detect appxbundle and automatically add all of the architectures - skipping the prompt entirely. This would be very easy if the architectures were an array field, and would still be possible if it required individual installer nodes

JohnMcPMS commented 2 years ago

I think that neutral still has a place, even if it is not commonly used. It probably shouldn't be used most of the time, but there are truly neutral runtimes (AnyCPU .Net[?], WWA, PWA, maybe just a bunch of python scripts delivered via .zip in the future) and data only packaging formats (archives, MSI [can be], MSIX). When x128 or M1 comes along, we want the existing manifests to "just work" rather than have to be updated to mention that a truly neutral package is also ok on the new hot thing.

Obviously, the downside is abuse of neutral, which can be true even for things that install everywhere right now. They might not in the future when some new architecture is available. It really only applies to interpreted code, not machine code.

Trenly commented 2 years ago

I think that neutral still has a place, even if it is not commonly used. It probably shouldn't be used most of the time, but there are truly neutral runtimes (AnyCPU .Net[?], WWA, PWA, maybe just a bunch of python scripts delivered via .zip in the future) and data only packaging formats (archives, MSI [can be], MSIX). When x128 or M1 comes along, we want the existing manifests to "just work" rather than have to be updated to mention that a truly neutral package is also ok on the new hot thing.

Obviously, the downside is abuse of neutral, which can be true even for things that install everywhere right now. They might not in the future when some new architecture is available. It really only applies to interpreted code, not machine code.

I would counter by saying that interpreted code would not rely on the Architecture field at all if that were the case; Given that it would have its own installer type, there would be no benefit to specifying the architecture as it would likely be ignored. Rather, I think this is a case where some scripters may use functions or modules which only support certain architectures, which (in my opinion) would lead to such installer types benefitting from explicitly requiring all supported architectures to be stated, as it would completely eliminate any chance for abuse

I can understand the backwards compatibility portion, that I will conpletely agree with.

All in all, I suppose the main request is for Architecture to be an array type of supported architectures, as that would help reduce the number of installer nodes and allow the community easier moderation and validation of manifest data