[Request] Allow Links (symlinks) to be created even if ArchiveBinariesDependOnPath is true

Relevant area(s)

WinGet CLI

Description of the new feature / enhancement

I'll include a list of relevant issues/pr/discussion post below. Also, I consider myself still a novice when it comes to winget so please be patient if there are some things I don't understand or were already considered/disregarded for various reasons.

Personally, I'm faced in a predicament in which I have to manually update the ffmpeg library location for various of my third-party applications that don't rely on using the binary from my path/allow me to use a custom build (eg. LosslessCut) or which require a dll (eg. Audacity). The reason why I have to manually do it myself is because of the manifest relying on ArchiveBinariesDependOnPath. As a result. the binaries are not placed in the Links folder; however, if you remove ArchiveBinariesDependOnPath, IIRC, there was some issue with symlinked binaries not finding the respective dll files (I assume this was because they were provided within the ZIP's /bin/ where the actual binaries are stored, and that path isn't added if ArchiveBinariesDependOnPath is false/unset).

The code execution cannot proceed because x.dll was not found. ReinstaIIing the program may fix this problem.

However, if winget were to create symlinks (Links) even while setting ArchiveBinariesDependOnPath to true, most problems would go away.

1. The dll not found gets resolved because now there would be Links in the Links folder and due to ArchiveBinariesDependOnPath: true we would also have the path set and therefore the required dll deps.
2. Users can now simply point their third-party applications to use the ffmpeg binary located in their Portable Links Directory folder (eg. %LOCALAPPDATA%\Microsoft\WinGet\Links) without worrying about future updates causing an outdated path issue.

I'm not technically verse with winget and package managers, so I'm not sure if this would be the perfect solution. Although, it's a potential solution that worked in my given case. I cloned the current manifests (https://github.com/microsoft/winget-pkgs/blob/master/manifests/g/Gyan/FFmpeg/Shared/9.0/Gyan.FFmpeg.Shared.installer.yaml) and removed ArchiveBinariesDependOnPath. I then installed the local manifest. Lastly, I added the created ffmpeg-9.0-full_build-shared\bin to my PATH env. variable manually. I was able to call ffmpeg -version successully without a missing dll issue and I was able to point LosslessCut with a custom ffmpeg path set to C:\Users\<user>\AppData\Local\Microsoft\WinGet\Links successfully.

Although, I believe I would still have to manually point some applications like Audacity to the \Packages\...\ffmpeg-shared\build\bin because it requires a specific dll. Not sure if we can PortableCommandAlias with non executables as I've never tested it, but I suppose doing that could resolve this too. I'm also waiting on Audacity being updated to support ffmpeg 9.0 so again, I can't test this at the moment or even see if pointing it to ffmpeg.exe would be fine in itself.

See also:
- Original Issue: https://github.com/microsoft/winget-cli/issues/2711
- Implemented fix: https://github.com/microsoft/winget-cli/pull/4816
- My issue: https://github.com/microsoft/winget-pkgs/issues/326439
- My question/discussion: https://github.com/microsoft/winget-pkgs/discussions/414772

Proposed technical implementation details

Of course, you all would know the best course of action here. Ideally, I think it would be better to add a flag to winget cli which allows us to also create symlinks regardless of ArchiveBinariesDependOnPath's value. That way, manifests won't have to change depending on someone's current setup. Instead, if a user has a special case like mine, they could simply enable the flag for either install or update.

Start by reviewing the WinGet CLI handling for ArchiveBinariesDependOnPath, PortableCommandAlias, and the Links directory. Read the linked original issue and implemented pull request for existing constraints, then determine where install and update options are parsed. Done means a well-defined opt-in behavior creates the requested symlinks without breaking archive dependency resolution.