-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
identity: remove requirement for coreos-assembler.basearch
#876
Conversation
This is aiming to increase compatibility of zincati with systems that aren't derived from Fedora CoreOS (e.g. IoT, desktop systems, etc.) Additionally, even in the FCOS case, when one derives a container image from FCOS, the final build isn't generated by coreos-assembler and hence the ostree commit won't have this metadata. In the end - I can't think of a use case for even trying to have zincati managing an image for a different architecture than the one it's compiled for. So, copy the code I wrote for oci-spec-rs which maps from the Rust architecture to the GNU one. xref containers/oci-spec-rs@52e450e
This is effectively a revert of #58, and I'm fine with merging this. /cc @jlebon |
OK, if you want to look at it we can - here's the neat thing, with this move we can use the standard container image metadata. Specifically I can change things (in the container case) to call https://docs.rs/ostree-ext/latest/ostree_ext/container/store/fn.query_image_ref.html and we can dig from there into https://docs.rs/oci-spec/0.5.8/oci_spec/image/struct.ImageConfiguration.html#method.architecture (However, we would then need to re-map the Go/OCI architecture back to GNU, we have Go code for that in https://github.com/coreos/stream-metadata-go/blob/main/arch/arch.go that we'd need to put somewhere in Rust) |
// Translate the architecture we were compiled for to the | ||
// output from the `arch` command that is used for RPM and | ||
// coreos-assembler builds. | ||
pub(crate) fn current_architeture() -> &'static str { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've been thinking about this more, and I think
is covered by coreos/stream-metadata-rust#34 We could also instead add rpm-ostree (really libdnf)'s idea of the architecture name into But, I'm still not sure that the original change was really strongly motivated; we don't have any case for cross-architecture updates, so again the architecture that we built for Rust must be the same as the RPM/GNU/Linux one - after a suitable mapping. So it's more about maintaining that suitable mapping in a sustainable way, and I do think the stream-metadata-rust PR is that. |
coreos-assembler.basearch
coreos-assembler.basearch
This is aiming to increase compatibility of zincati with systems that aren't derived from Fedora CoreOS (e.g. IoT, desktop systems, etc.)
Additionally, even in the FCOS case, when one derives a container image from FCOS, the final build isn't generated by coreos-assembler and hence the ostree commit won't have this metadata.
In the end - I can't think of a use case for even trying to have zincati managing an image for a different architecture than the one it's compiled for.
So, copy the code I wrote for oci-spec-rs which maps from the Rust architecture to the GNU one. xref
containers/oci-spec-rs@52e450e