Skip to content

Provides package overriding actual concrete package #212

Description

@jseba

Not exactly sure how to describe the title, please feel free to update it for clarity.

I'm running into an issue on the latest v0.6.2 where if there are two packages, foo and foo-plus, where foo-plus also Provides: foo, then rules_distroless will always resolve the manifest entry foo as foo-plus. If I'm understanding the code right, "provides" packages always take precedence over any actual packages that share that name. This is a significant departure from how apt works on normal Debian systems, where if you do apt-get install foo, it will always prefer a concrete package over any other package that also Provides: foo, unless there are other constraints on the package set to change its mind.

While this is a surprising behavior, I'd be able to live with it as a quirk if there were any way of actually forcing the resolver to use the concrete package, but I can't seem to find one. My basic attempt to simply invert the lookup such that virtual packages are only checked if no other package is found has a different quirk in the opposite direction, where listing a virtual package in the manifest will make it pick the concrete one so you end up with a different name in the BUILD files.

For a specific case (on both), here's a manifest for two packages that have said broken/odd behaviors

version: 1

sources:
  - channel: trixie main
    url: https://deb.debian.org/debian
  - channel: trixie-security main
    url: https://deb.debian.org/debian-security
  - channel: trixie-updates main
    url: https://deb.debian.org/debian

archs:
  - amd64
  - arm64

packages:
  - sudo
  - rng-tools

When rules_distroless tries to resolve sudo, it ends up resolving to sudo-ldap and sudo doesn't exist in the BUILD tree. Not only is this not obvious, it also means that you didn't get the package you specified and in this case, a lot of extra dependencies. For rng-tools (and my local patch) I now have to use rng-tools-debian explicitly in my BUILD rules, but this isn't that terrible since rng-tools is just an empty package and depends on rng-tools-debian.

I don't think my attempt at simply moving the virtual package resolution to after any attempts for concrete ones is properly correct, there's probably corner cases it breaks, but it does pass the tests in the repo and my regression tests, so I've attached it here as a patch. If it does look okay, I can open a PR for review.

rules_distroless-virtual-fallback.patch

Activity

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions