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.
- 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.
- 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: #2711
- Implemented fix: #4816
- My issue: microsoft/winget-pkgs#326439
- My question/discussion: microsoft/winget-pkgs#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.
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 onArchiveBinariesDependOnPath. As a result. the binaries are not placed in the Links folder; however, if you removeArchiveBinariesDependOnPath, IIRC, there was some issue with symlinked binaries not finding the respectivedllfiles (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 ifArchiveBinariesDependOnPathis false/unset).However, if winget were to create symlinks (Links) even while setting
ArchiveBinariesDependOnPathtotrue, most problems would go away.dllnot found gets resolved because now there would be Links in the Links folder and due toArchiveBinariesDependOnPath: truewe would also have the path set and therefore the requireddlldeps.ffmpegbinary 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 createdffmpeg-9.0-full_build-shared\binto my PATH env. variable manually. I was able to callffmpeg -versionsuccessully without a missingdllissue and I was able to point LosslessCut with a custom ffmpeg path set toC:\Users\<user>\AppData\Local\Microsoft\WinGet\Linkssuccessfully.Although, I believe I would still have to manually point some applications like Audacity to the
\Packages\...\ffmpeg-shared\build\binbecause it requires a specificdll. Not sure if we canPortableCommandAliaswith 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: #2711
- Implemented fix: #4816
- My issue: microsoft/winget-pkgs#326439
- My question/discussion: microsoft/winget-pkgs#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 eitherinstallorupdate.