[Package Issue]: libvips.libvips

Open Beginner friendly
  • Is something wrong?
#471,261 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
72/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
powershell
Domain
devops

Research direction

Start with the installer manifest at manifests/l/libvips/libvips/8.18.7/libvips.libvips.installer.yaml and check how its portable ZIP installer configures command aliases and PATH. Compare that setup with the reported Scoop manifest behavior. Done means installing the package makes vips --version print vips-8.18.7 from a new terminal, as described in the issue.

Written by the indexing model from the issue text.

Description

Needs-Triage
Please confirm these before moving forward
  • I have searched for my issue and not found a work-in-progress/duplicate/resolved issue.
  • I have not been informed if the issue is resolved in a preview version of the winget client.
Category of the issue

Installation issue.

Brief description of your issue

After winget install libvips.libvips, running vips (or vipsheader / vipsthumbnail) from a terminal exits immediately with no output.

The manifest installs the package as zip + NestedInstallerType: portable with PortableCommandAlias, so WinGet creates symlinks in %LOCALAPPDATA%\Microsoft\WinGet\Links\. vips.exe depends on dozens of DLLs that sit next to it in vips-dev-8.18\bin\ (libvips-42.dll, libglib-2.0-0.dll, ...). When the process is started through the symlink, the loader uses the symlink's directory (Links\) as the application directory, so none of those DLLs are found and the process dies with STATUS_DLL_NOT_FOUND (0xC0000135). PowerShell/cmd print nothing, which makes it look like a silent no-op.

Running the real bin\vips.exe by its full path works fine.

Suggested fix: add ArchiveBinariesDependOnPath: true to the installer manifest so WinGet adds the bin directory to PATH instead of creating symlinks. This is what the Scoop manifest for libvips does (env_add_path: bin).

Steps to reproduce

Make sure no other libvips bin directory is on PATH (one would mask the problem, because the DLLs then resolve via PATH).

winget install --id libvips.libvips --exact
# new terminal
vips --version
$LASTEXITCODE

# compare with the real binary
& (Get-Item "$env:LOCALAPPDATA\Microsoft\WinGet\Links\vips.exe").Target --version
Actual behavior
PS> vips --version
PS> $LASTEXITCODE
-1073741515          # 0xC0000135 STATUS_DLL_NOT_FOUND

PS> & (Get-Item "$env:LOCALAPPDATA\Microsoft\WinGet\Links\vips.exe").Target --version
vips-8.18.7

Links\vips.exe is a SymbolicLink targeting ...\Packages\libvips.libvips_Microsoft.Winget.Source_8wekyb3d8bbwe\vips-dev-8.18\bin\vips.exe.

Expected behavior

vips --version prints vips-8.18.7 from any directory, as it does when the real bin\vips.exe is run directly.

Environment
Windows Package Manager v1.29.380
Windows: Windows.Desktop v10.0.26300.9711
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.29.380.0

libvips.libvips 8.18.7 (x64)
Screenshots and Logs

Manifest: https://github.com/microsoft/winget-pkgs/blob/master/manifests/l/libvips/libvips/8.18.7/libvips.libvips.installer.yaml

Dominant language
No language data
Stars
11.3k
Forks
11.8k
Avg merge
6h 46m
Merged PRs (30d)
435

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from microsoft/winget-pkgs

All issues in microsoft/winget-pkgs

Similar issues

More DevOps issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.