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
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,
fooandfoo-plus, wherefoo-plusalsoProvides: foo, then rules_distroless will always resolve the manifest entryfooasfoo-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 doapt-get install foo, it will always prefer a concrete package over any other package that alsoProvides: 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
When rules_distroless tries to resolve
sudo, it ends up resolving tosudo-ldapandsudodoesn'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. Forrng-tools(and my local patch) I now have to userng-tools-debianexplicitly in my BUILD rules, but this isn't that terrible sincerng-toolsis just an empty package and depends onrng-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