Might work. We just make it still the one release that contains the same old binary names, they just are now written in rust. The one disadvantage is that it makes it harder for us to drop the C library if it is part of the same module.

I don't think we should merge them in the repo unless we expect to release them in sync. I.e. one tarball release, one srpm, etc. I.e. we don't want to share repo/issues/tags for something that is two separate "upstream modules". That way lies madness.

I strongly agree. Also: composefs-rs isn't anywhere near the same level of maturity. There are still massive refactors going down in that repo on a semi-regular basis...

Make the rust code be able to generate compatible v1.0 images (boring but important for looking like a serious project)

Let's discuss this in more detail because it is quite important. I think there are really three very different cases when it comes to this:

composefs unsigned

The status quo for both bootc and c/storage. composefs is used just as an extra layer of readonly; we don't have any requirements on the reproducibility of the composefs blob.

composefs for booting

• ostree with signed composefs
• The composefs-rs secureboot-unified
• Probably others! (rauc?)

My assertion here is that most of these use cases are going to be fine just picking one of composefs-c or composefs-rs and they're generally in a good position to control "skew" between the build system and the client.

Let's say that someone is using composefs-c today with ostree or is using rauc and they want to switch to composefs-rs (with other format breaks, maybe SHA512, opting in to hard requiring newer kernels etc).

In this case they need to ensure that their build system and the client build get updated in one step. It's not trivial but it's not seriously difficult either I would say. Right?

composefs for OCI with precomputed label

This is the one discussed in #294 etc. In this world, "skew" becomes a hugely important problem (as discussed there) because we will have use cases with old containers being run on newer hosts, even multiple distinct build systems that wire up composefs computation etc.

And this is why I will continue to strongly argue for the "canonical dumpfile digest" that I was advocating in that thread because it unties us from all concerns about exact EROFS reproducibility...and hence from needing to care about the current differences between composefs-c and composefs-rs.
(It doesn't untie us from SHA256 vs SHA512 though...)

Ok, I generally agree with this.

Although I think we will do our users a service if we allow composefs-c to at least produce the new composefs-rs format. Then we allow users to update the host side and build side separately (i.e. you can keep the build side yet move forward on the deploy side, and later update the build side).

We could start with a build option to not build the tools i guess.

containers/storage uses mkcomposefs to generate the EROFS from the dump format

@giuseppe Yeah, the idea was to make the rust code supply a compatible binary.

I'm not sure we want to immediately archive composefs-c, as we have it in supported products (like RHEL9) yet, and we want to be able to do changes in it still, if we have say security issues.

I think we want to do a final update to it, adding a --without-tools compile option, and adding support for the composefs-rs image version, and then we'll keep it around non-archived for a few years with a big warning sign pointing to composefs-rs.