Is there a way to force WinGet to create Links in addition to aliases? (Gyan.FFmpeg.Shared)

[infinity (Infinitay)]

cc: #326439

The package Gyan.FFmpeg.Shared is a release that contains dlls and other libraries/source code. Initially, IIRC I had an issues where the package was not creating/distributing the binaries (#326439). However, thankfully someone took the time to fix that problem. Though, overtime, I've realized that I manually have to update various applications that depend on me providing a path to my ffmpeg binaries.

I don't have issues using various ffmpeg binaries within my terminal, but other applications don't recognize it because I'm assuming it's not directly in my path. I didn't have this issue in the past because there were links available in my Portable Links Directory (User) folder. However, because of this specific package version being meant for having dlls available and other source code, I guess there's no proper Link being created.

Is there a winget flag or manifest flag which maintains the current behavior of extracting the ffmpeg shared as separate dlls and libraries in addition to the compiled binaries within the /bin/ folder, but also have winget create a Link to those binaries found within /bin/?

Not sure if this'll help but here's a winget package update log (via UniGetUI)

Package install operation for Package=Gyan.FFmpeg.Shared with Manager=Winget
Installation options: <InstallOptions instance (only non-default values are shown)
	OverridesNextLevelOpts: False>
Overriden options: <Scope=;RunAs****istrator=;WG_SpecifyVersion=;PS_NoScope=False;Pip_BreakSystemPackages=False;WG_DropArchAndScope=False>
Starting operation...
Executing process with StartInfo:
 - FileName: "C:\Users\<user>\AppData\Local\Microsoft\WindowsApps\winget.exe"
 - Arguments: "install --id "Gyan.FFmpeg.Shared" --exact --source winget --accept-source-agreements --disable-interactivity --silent --accept-package-agreements --force"
Start Time: "8/5/2026 8:24:12 PM"
Found FFmpeg (Shared) [Gyan.FFmpeg.Shared] Version 9.0
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
Successfully verified installer hash
Extracting archive...
Successfully extracted archive
Starting package install...
Path environment variable modified; restart your shell to use the new value.
Command line alias added: "ffmpeg"
Command line alias added: "ffplay"
Command line alias added: "ffprobe"
Successfully installed
End Time: "8/5/2026 8:24:18 PM"
Process return value: "0" (0x0)
FFmpeg (Shared) was installed successfully

Folder structure

Hierarchy
─────────
└───ffmpeg-9.0-full_build-shared
    ├───doc
    ├───include
    │   ├───libavcodec
    │   ├───libavdevice
    │   ├───libavfilter
    │   ├───libavformat
    │   ├───libavutil
    │   ├───libswresample
    │   └───libswscale
    ├───lib
    └───presets

[GraphiqStudioLLC (Codebater)]

There's no flag for this — whether a link shows up in the Links directory is decided entirely by the package's manifest, not by anything you can pass to winget install.

For zip-based packages, links are only created for files the manifest explicitly declares under NestedInstallerFiles with a PortableCommandAlias. The regular Gyan.FFmpeg manifest declares ffmpeg/ffprobe/ffplay that way, which is why you got links with it in the past. Gyan.FFmpeg.Shared is treated as "a folder of libraries" — nothing in bin/ is declared as a command, so winget extracts it and stops there. Same installer type, different manifest intent.

So, practical options in order of how much they annoy you:

1. Install plain Gyan.FFmpeg alongside the Shared one. You keep the dlls from Shared for the apps that need them, and the portable package gives you the linked binaries on PATH. Slightly redundant on disk, zero maintenance.
2. Add the Shared bin/ folder to your user PATH yourself — but the extraction folder is version-named, so it silently breaks on every update, which is exactly the problem the Links directory exists to solve. I wouldn't.
3. The actual fix: a manifest change adding PortableCommandAlias entries for the exes in bin/ of the Shared package. That's a normal PR against this repo (the manifests live under manifests/g/Gyan/FFmpeg/Shared/), and given the exes ship in the archive anyway it seems like a reasonable ask. Might be worth checking with the maintainers whether it was left out on purpose — some "shared" packages skip aliases specifically so they don't fight with the portable variant over the same command names.

If you don't want to write the PR yourself, opening an issue on the package pointing at the missing PortableCommandAlias is the way to get it in front of the right people.

[infinity (Infinitay)]

Appreciate the help but think the AI you used is missing some details.

1. I don't want to do this because IIRC Gyan.FFmpeg and Gyan.FFmpeg.Shared are different in contents. The shared version includes more libraries for a lack of better terms.
2. I assume this would work, but the whole point of wanting the Links to be created would be to avoid manually updating ffmpeg's location on my applications. I can already call ffmpeg and other binaries in my terminal. My problem is that other applications require a ffmpeg path, and when using the shared version, I would have to be manually changing it regardless.
3. Pretty sure this is an invalid because the Shared manifest already has PortableCommandAlias defined. Guess the LLM missed it.

   winget-pkgs/manifests/g/Gyan/FFmpeg/Shared/9.0/Gyan.FFmpeg.Shared.installer.yaml

   Line 10 in a814a4e

   PortableCommandAlias: ffmpeg