composefs: Read manifest+config from composefs repo instead of .imginfo#2044
composefs: Read manifest+config from composefs repo instead of .imginfo#2044cgwalters wants to merge 3 commits intobootc-dev:mainfrom
Conversation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request refactors how container image manifest and configuration are handled for composefs deployments. Instead of storing them in a separate .imginfo file, the manifest digest is now stored in the .origin file, and the manifest/config are read directly from the composefs repository. This is a good improvement that centralizes image metadata storage. The changes are consistent across the codebase, and backward compatibility for older deployments with .imginfo files is maintained. I've found one area for improvement regarding repository handling efficiency.
cgwalters
force-pushed
the
prep-composefs-manifest
branch
2 times, most recently
from
0d8ac87 to
ef5cb0f
Compare
Needed for handling GC later. Assisted-by: OpenCode (Claude claude-opus-4-6) Signed-off-by: Colin Walters <walters@verbum.org>
Update to the latest API here, just on general principle since it gives us logging info which we use. Assisted-by: OpenCode (Claude Opus 4) Signed-off-by: Colin Walters <walters@verbum.org>
The latest composefs-rs stores manifest and config objects and the manifest becomes a GC root, so we can use that instead of `.imginfo` sidecar files. The flow now is: bootloader entry -> deployment -> origin file -> manifest digest -> manifest -> [config | objects] For backward compatibility, fall back to the legacy .imginfo file if the .origin does not contain a manifest_digest key. Drop the really old hacky fallback that did network fetches. Note the manifest becomes part of the GC root. Assisted-by: OpenCode (Claude claude-opus-4-6) Signed-off-by: Colin Walters <walters@verbum.org>
cgwalters
force-pushed
the
prep-composefs-manifest
branch
from
ef5cb0f to
d1f366d
Compare
|
OK, this is passing tests now and I think is a notable cleanup. I think this may be one of the last ~breaking changes for the composefs installation layout. |
|
Actually thinking about this more...it feels like we should really be creating tags in the cfs repo instead of using this additional root stuff. That's effectively what ostree does with Basically we create
In particular a key thing is that this works if the composefs repo holds other data such as app images. |
1 participant
The latest composefs-rs stores manifest and config objects and
the manifest becomes a GC root, so we can use that instead of
.imginfosidecar files.
The flow now is:
bootloader entry -> deployment -> origin file
-> manifest digest -> manifest -> [config | objects]
For backward compatibility, fall back to the legacy .imginfo
file if the .origin does not contain a manifest_digest key.
Drop the really old hacky fallback that did network fetches.
Note the manifest becomes part of the GC root.