bottlerocket-os / bottlerocket-os/twoliter

build package does not work with cargo resolver 2

Open
#45 0 comments 0 reactions 0 assignees View on GitHub
bug
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.