investigate: why do we need a separate layer for the .rock metadata?
Metadata
Current evaluation
Maintainer-led investigation into why /.rock/metadata.yaml is emitted as its own OCI layer and whether it can be squashed; work remains pending store-ingestion compatibility analysis.
Suggested action: keep open
Reason: rockcraft/oci.py:set_control_data explicitly archives .rock/metadata.yaml and adds it with the history entry "Add rock control metadata," confirming the separate-layer behavior. @lengau noted that the store team must assess it because ingestion may depend on layer structure; no resolving change or agreed replacement design is evident.
Evaluated by: mr-cal-bot
Impact:
42
Quick Win:
10
Complexity:
62
Confidence:
91
Actionability:
64
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 |
|---|---|---|---|---|
| stealth/space-bunny-alpha |
Impact:
42
Quick Win:
10
Complexity:
62
Confidence:
91
Actionability:
64
|
keep open | Maintainer-led investigation into why /.rock/metadata.yaml is emitted as its own OCI layer and whether it can be squashed; work remains pending store-ingestion compatibility analysis. | |
| qwen/qwen3.6-35b-a3b |
Impact:
30
Quick Win:
11
Complexity:
40
Confidence:
70
Actionability:
60
|
needs triage | Investigation request about why .rock metadata is stored as a separate OCI layer instead of being squashed with other parts; open with no labels or triage. | |
| qwen/qwen3.8-27b |
Impact:
30
Quick Win:
14
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. |
Update history
No update history recorded yet.
Related issues
No related issues found above the similarity threshold.