investigate: why do we need a separate layer for the .rock metadata?
Metadata
Current evaluation
Investigation request to revisit why the .rock/metadata.yaml is packed as a separate OCI layer instead of being squashed with other parts. Open, 1 comment from a maintainer noting store ingestion implications; no labels or assignee.
Suggested action: needs triage
Reason: The issue is an open investigation request with no labels, no assignee, and only one comment (from @lengau on 2026-04-02) flagging that a separate layer could affect how the store team ingests rocks. The code path (set_control_data in rockcraft/oci.py) still adds the metadata as its own layer, so the question remains unresolved and needs triage/decision.
Impact:
30
Quick Win:
13.5
Staleness:
45
Complexity:
55
Confidence:
60
Support Request:
5
Issue body
### Check existing issues
- [x] I've verified that this request isn't described by any existing issues.
### Request
This is a request for further investigation, related to the fact that the .rock metadata file seems to be packed into the rock as a separate layer.
This must have been a conscious decision? (especially assuming that all parts are squashed). But why? atm, I don't see much value in having it that way, since that layer is always going to be very specific to each rock and thus not that reusable.
It would be good to revisit this decision and potentially consider squashing it with the rest of the other parts, if it makes sense.
### The problem it solves
Makes the layer creation more consistent with the rest of the parts and removes the additional tiny layer from the OCI config.
Evaluation history
| Date | Model | Scores | Action | Summary |
|---|---|---|---|---|
| qwen/qwen3.8-27b |
Impact:
30
Quick Win:
13.5
Staleness:
45
Complexity:
55
Confidence:
60
Support Request:
5
|
needs triage | Investigation request to revisit why the .rock/metadata.yaml is packed as a separate OCI layer instead of being squashed with other parts. Open, 1 comment from a maintainer noting store ingestion implications; no labels or assignee. | |
| qwen/qwen3.6-35b-a3b |
Staleness:
45
Complexity:
75
Confidence:
80
Support Request:
10
|
needs triage | Investigation into whether the .rock metadata layer should be squashed with other layers instead of remaining separate. Currently unlabelled and awaiting cross-team review with the store team. | |
| qwen3.6-35b-a3b-mtp-q6 |
Staleness:
45
Complexity:
25
Confidence:
80
Support Request:
0
|
needs triage | Investigation request regarding why .rock metadata is stored as a separate OCI layer instead of being squashed. Currently unlabelled and inactive for 96 days. | |
| qwen3.6-35b-a3b-mtp-q6 |
Staleness:
55
Complexity:
45
Confidence:
75
Support Request:
10
|
needs triage | Investigation into whether .rock metadata should be squashed into a single layer instead of a separate OCI layer. Currently awaiting coordination with the store team. | |
| qwen3.6-35b-a3b-mtp-q6 |
Staleness:
60
Complexity:
60
Confidence:
85
Support Request:
10
|
needs triage | Investigates why .rock metadata uses a separate OCI layer instead of being squashed. Aims to streamline layer creation and remove redundant layers. Currently open, pending store team review on ingestion impacts. Inactive for 74 days. |
Update history
No update history recorded yet.
Related issues
No related issues found above the similarity threshold.