bottlerocket-os / bottlerocket-os/twoliter
build package does not work with cargo resolver 2
- Dominant language
- Rust
- Stars
- 34
- Forks
- 43
- Avg merge
- 11h 13m
- Merged PRs (30d)
- 16
Description
## Description
https://github.com/bottlerocket-os/bottlerocket/issues/3372#issuecomment-1697915468
> Running cargo make -e PACKAGE=libfoo build-package results in running cargo build --manifest-path variants/Cargo.toml --package libfoo. This reproduces the error a little faster.
>
> The key to understanding the error lies in the new Cargo feature resolver v2 separating activated features by both package and where/when it is going to be used. When checking for activated features of a package, Cargo takes both into account. It bails when it unexpectedly cannot find a combination of {package, where to use it}.
>
> The following is my current understanding of the matter, but it is to be taken with a grain proper amount of salt:
We are using dependencies and build-dependencies in the Cargo manifests for specifying runtime and buildtime dependencies both for the target architecture which is a bit different from what Cargo uses these for. Specifying a dependency in the build-dependencies section of a manifest, I believe, activates features in this dependency package as HostDep. When:
>
> a variant is built, the roots of all (RPM) package trees to pull into the final image are likewise defined as build-dependencies (e.g. in variants/metal-dev/Cargo.toml). When resolving the feature set for dependencies upon building these top-level packages (already known as HostDeps), Cargo looks for and finds their (and their transitive) dependencies also as HostDep.
>when just building a single package it is looking for activated features in a NormalOrDev context for the single target to be built (e.g. libfoo)--while still knowing libfoo and all of its dependencies as HostDep only.
I'm not sure what would a good way to resolve this would look like. Perhaps reverting to the feature resolver v1 and accepting warnings is the lesser evil for now, so we can avoid the problem by having the unified feature namespace.
## Definition of Done
When Bottlerocket and any other Twoliter project can use `build package` with workspace resolvers set to v2.
Contributor guide
Research direction
Start by reproducing `cargo make -e PACKAGE=libfoo build-package`, which runs `cargo build --manifest-path variants/Cargo.toml --package libfoo`, with Cargo workspace feature resolver v2 enabled. Read the workspace manifests and compare dependency contexts to determine a compatible resolution. Done means Bottlerocket and other Twoliter projects can use `build package` with workspace resolvers set to v2.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- build-system, tooling
- Issue type
- Bug
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100