support ostree-ext tar mode #2499
Comments
cgwalters
added a commit
to cgwalters/ostree-rs-ext
that referenced
this issue
Dec 17, 2021
Part of ostreedev/ostree#2499 Basically, ostree core should have first-class support for reading and parsing this. The primary motivation is to support ostree-in-container better. The real main wrinkle here is xattrs, as usual. We can't rely on being able to read/write xattrs inside a container. For now, this will serve sufficient to *identify* this format, but it will pave the way for ostree core to support read/write. (Note that if we go to implement writes, a notable wrinkle is that garbage collection of the `xattrs` subdirectory will require another special handling pass)
cgwalters
added a commit
to cgwalters/ostree-rs-ext
that referenced
this issue
Dec 17, 2021
Part of ostreedev/ostree#2499 Basically, ostree core should have first-class support for reading and parsing this. The primary motivation is to support ostree-in-container better. The real main wrinkle here is xattrs, as usual. We can't rely on being able to read/write xattrs inside a container. For now, this will serve sufficient to *identify* this format, but it will pave the way for ostree core to support read/write. (Note that if we go to implement writes, a notable wrinkle is that garbage collection of the `xattrs` subdirectory will require another special handling pass)
cgwalters
added a commit
to cgwalters/ostree-rs-ext
that referenced
this issue
Dec 18, 2021
Part of ostreedev/ostree#2499 Basically, ostree core should have first-class support for reading and parsing this. The primary motivation is to support ostree-in-container better. The real main wrinkle here is xattrs, as usual. We can't rely on being able to read/write xattrs inside a container. For now, this will serve sufficient to *identify* this format, but it will pave the way for ostree core to support read/write. (Note that if we go to implement writes, a notable wrinkle is that garbage collection of the `xattrs` subdirectory will require another special handling pass)
cgwalters
added a commit
to cgwalters/ostree-rs-ext
that referenced
this issue
Dec 20, 2021
Part of ostreedev/ostree#2499 Basically, ostree core should have first-class support for reading and parsing this. The primary motivation is to support ostree-in-container better. The real main wrinkle here is xattrs, as usual. We can't rely on being able to read/write xattrs inside a container. For now, this will serve sufficient to *identify* this format, but it will pave the way for ostree core to support read/write. (Note that if we go to implement writes, a notable wrinkle is that garbage collection of the `xattrs` subdirectory will require another special handling pass)
|
Perhaps without going into the uncharted territory of linking the C and Rust codebases together, for the moment it could be enough to investigate a "metadata read-only" mode purely in C here. |
|
Having it be read-only would definitely be a useful start. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Today https://github.com/ostreedev/ostree-rs-ext/ implements effectively a new repository mode. The main thing is that we split off xattrs into a separate content-addressed file; partly because I was uncertain about xattrs making it through tar transformations.
We should support all ostree operations here, both reads and commits. This will involve some code duplication with ostree-rs-ext unfortunately due to the Rust/C problem. Or...in theory we could try to expose a hidden but stable C API from ostree-rs-ext as a C shared library...but, eek.
The text was updated successfully, but these errors were encountered: