Skip to content

Conversation

@gergondet-woven
Copy link
Contributor

@gergondet-woven gergondet-woven commented Nov 25, 2025

This fixes some edge-cases with virtual packages resolution introduced in #146

  • Sometimes multiple versions of the same package are available, just pick the most recent one
  • Fix comparison in version_constraint
  • Sometimes virtual packages are not in the arch folder

One way to reproduce this is to use the following manifest slightly adapted from the examples folder to:

  • add the curl package that will have several of the issues solved by this patch
  • bump the snapshot time
Example manifest
version: 1

sources:
  - channel: noble main
    url: https://snapshot.ubuntu.com/ubuntu/20250930T150000Z
  - channel: noble-security main
    url: https://snapshot.ubuntu.com/ubuntu/20250930T150000Z
  - channel: noble-updates main
    url: https://snapshot.ubuntu.com/ubuntu/20250930T150000Z

archs:
  - "amd64"
  - "arm64"

packages:
  - "ncurses-base"
  - "libncurses6"
  - "tzdata"
  - "bash"
  - "coreutils" # for commands like `ls`
  - "grep"
  # for apt list --installed
  - "dpkg"
  - "apt"
  - "perl"
  - "curl"

This will build but you should see the following warning messages with the current main version:

DEBUG: [cache]/external/rules_distroless+/apt/private/apt_dep_resolver.bzl:40:14: 
Multiple candidates for virtual package 'libnettle8': ["libnettle8t64", "libnettle8t64"]
DEBUG: [cache]/external/rules_distroless+/apt/private/apt_dep_resolver.bzl:40:14: 
Multiple candidates for virtual package 'libhogweed6': ["libhogweed6t64", "libhogweed6t64"]
WARNING: Following dependencies could not be resolved for curl: libnettle8,libhogweed6,libgnutls30
DEBUG: [cache]/external/rules_distroless+/apt/extensions.bzl:27:26:

The first two are solved by picking whichever of the package has the most recent version.

For the libgnutls30 issue reported here, I had to add some extra ouptut to figure things out. In this version of the snapshot, the package is required with a constraint >= 3.8.1 and the packages available in the snapshot have versions 3.8.3-1.1ubuntu3 and 3.8.3-1.1ubuntu4. They should both satisfy the constraint but because the operands are inverted they are rejected.

The last point is more peculiar. We saw this happen with the OpenVINO apt distribution (see here) but I think it's fairly reasonable to fallback to the all architecture just in case 🤔

- Sometimes multiple versions of the same package are available, just
  pick the most recent one
- Fix comparison in version_constraint
# First check if the constraint is satisfied by a virtual package
virtual_packages = state.repository.virtual_packages(name = name, arch = arch)
if not len(virtual_packages):
virtual_packages = state.repository.virtual_packages(name = name, arch = "all")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should this be merged with other arch virtual packages even if there are some?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a good point. In the case we encountered there was no arch-specific virtual package but some all virtual package but I don't think it's impossible to have some of both?

I have changed the code to extend the initial list with the one from the all architecture.

fail("Per https://www.debian.org/doc/debian-policy/ch-relationships.html only = is allowed for Provides field.")

return _version_relop(va[1], vb[1], va[0])
return _version_relop(vb[1], va[1], va[0])
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you explain this change?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

_version_relop(va, vb, op) will return the result of va {op} vb

In the context of is_satisfied_by, va is a constraint (e.g. >= 3.8.1) and vb is a version to be tested (e.g. = 3.8.3-1.1ubuntu4) so before this change we end up testing {constraint_version} {constraint_op} {test_version} (e.g. 3.8.1 >= 3.8.3-1.1ubuntu4) which rejects viable candidates (and could accept wrong candidates).

With this change we do the correct operation.

Note that there is some tests here but they all pass because for these specific test cases the inversion doesn't matter. In particular if you change the last one to (">> 1.1", "= 1.0", False) or the second one to ("<= 1.1", "= 1.0", True), then the test fail on main. I'm happy to add a couple extra cases to this test in the PR 🙏

Copy link
Contributor Author

@gergondet-woven gergondet-woven left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the quick review.

I'm happy to add extra test cases to _is_satisfied_by_test to highlight the issue that was fixed 🙏

# First check if the constraint is satisfied by a virtual package
virtual_packages = state.repository.virtual_packages(name = name, arch = arch)
if not len(virtual_packages):
virtual_packages = state.repository.virtual_packages(name = name, arch = "all")
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a good point. In the case we encountered there was no arch-specific virtual package but some all virtual package but I don't think it's impossible to have some of both?

I have changed the code to extend the initial list with the one from the all architecture.

fail("Per https://www.debian.org/doc/debian-policy/ch-relationships.html only = is allowed for Provides field.")

return _version_relop(va[1], vb[1], va[0])
return _version_relop(vb[1], va[1], va[0])
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

_version_relop(va, vb, op) will return the result of va {op} vb

In the context of is_satisfied_by, va is a constraint (e.g. >= 3.8.1) and vb is a version to be tested (e.g. = 3.8.3-1.1ubuntu4) so before this change we end up testing {constraint_version} {constraint_op} {test_version} (e.g. 3.8.1 >= 3.8.3-1.1ubuntu4) which rejects viable candidates (and could accept wrong candidates).

With this change we do the correct operation.

Note that there is some tests here but they all pass because for these specific test cases the inversion doesn't matter. In particular if you change the last one to (">> 1.1", "= 1.0", False) or the second one to ("<= 1.1", "= 1.0", True), then the test fail on main. I'm happy to add a couple extra cases to this test in the PR 🙏

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants