Aleksa Sarai

This project is no longer actively maintained. However, [umoci] is a much more full-featured tool for manipulating OCI images, and is now an OCI project as a reference implementation of...

I would suggest using https://github.com/openSUSE/umoci instead -- `image-tools` has historically had many problems with unpacking things correctly and is the main reason I ended up writing `umoci`. It's used by...

Oh sorry, I didn't notice you already mentioned you tested against `umoci`. :wink: I could look into porting `image-tools` to `umoci` (the underlying libraries should be fairly reusable -- I...

This project is no longer actively maintained. However, [umoci] is a much more full-featured tool for manipulating OCI images, and is now an OCI project as a reference implementation of...

Whether we should eventually drop it is an entirely separate discussion. What's important right now is that we generate `config.json` payloads that are actually useful. cyphar/umoci#13 has my opinion on...

> @crazykev pay attention to this issue forocid work please I'm working on an unpacking library for umoci, because the one in this repo isn't really up-to-snuff (IMO). I will...

I also really like it, because it means that the CAS and other functions in `umoci` that will move here should in principle just be able to use the `context`...

The biggest problem with the other platforms is extraction. How do you (sanely) extract layers on a Windows filesystem (there's a huge number of knobs in `tar` that don't make...

To be honest, all I really want for `umoci` is if I can use an `[]idtools.IDMap` (or whatever the `runtime-spec` equivalent is) to specify what translation I would like during...

@hustcat Here's my opinion on the topic: 1. `skopeo` already exists. Not every project that implements OCI features needs to be under the umbrella of the OCI (this is important...