Fix APK resolver for version constraints on provided packages#1860
Open
AmberArcadia wants to merge 2 commits intomainfrom
Open
Fix APK resolver for version constraints on provided packages#1860AmberArcadia wants to merge 2 commits intomainfrom
AmberArcadia wants to merge 2 commits intomainfrom
Conversation
This fixes the issue where packages with version constraints weren't properly resolved when the package name was provided by another package with a version in the provides clause. Problem: - When resolving constraints like `py3-numpy<2.0`, the resolver would find packages that provide `py3-numpy` (e.g., `py3.12-numpy` with version 2.1.0) - The filterPackages function would incorrectly check the package's own version (2.1.0) against the constraint instead of checking the version specified in the provides clause - This caused APK to fail to find packages even when valid versions existed Solution: - Added queryName context to filterPackages to track which name was queried - Modified filtering logic to only check versions relevant to the queried name - For packages found via provides, check the version in the provides clause - For provides without explicit versions, fall back to package version This enables proper migration from py3-* packages to versioned Python packages (py3.XX-*) while maintaining correct dependency resolution. Fixes the numpy/pytorch build failures in Wolfi/Chainguard packages. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
|
As far as I can tell the tests added here work with the current version of apko: #1862 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This PR fixes a critical bug in the APK resolver that was causing numpy and pytorch packages to fail building in Wolfi/Chainguard. The resolver wasn't correctly handling version constraints when packages were found via their
providesentries.The Problem
When migrating from
py3-numpyto versioned packages likepy3.12-numpy, we hit an issue:Package structure:
py3.12-numpy(version 2.1.0) providespy3-numpy=2.1.0py3.12-numpy(version 1.26.4) providespy3-numpy=1.26.4py3-numpy<2.0The bug:
py3-numpy<2.0, APK would find packages providingpy3-numpypy3.12-numpyversion 2.1.0) against the constraintpy3-numpy=2.1.0)py3-numpy<2.0, even thoughpy3.12-numpy-1.26.4providespy3-numpy=1.26.4The Solution
This PR adds context awareness to the package filtering logic:
queryNameto track which name was used to find packagespy3-numpy<2.0, only checks versions relevant topy3-numpyWhy This Matters
This fix is critical for:
py3-*topy3.XX-*versioned packagesTesting
TestNumpyVersionConstraintWithProvidesthat reproduces the exact scenarioImpact
This fixes the current build failures in:
And enables the planned migration away from
py3-*packages as discussed in the incident.🤖 Generated with Claude Code
Co-Authored-By: Claude noreply@anthropic.com