Aleksa Sarai

On 10/27/2016 04:23 AM, W. Trevor King wrote: > On Wed, Oct 26, 2016 at 10:10:37AM -0700, Aleksa Sarai wrote: > > > > I disagree, and would much rather...

For those who are interested in `imagectl` (which I've currently just called `umoci` as a working name), I've written up a [quick design doc](https://github.com/cyphar/umoci/blob/master/DESIGN.md) on what I expect the final...

@stevvooe I've removed the file because all of the stuff in the design document has since been implemented in [`umoci`](https://github.com/cyphar/umoci) and the design document no longer accurately described how everything...

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...

This doesn't happen with the current state of the repo (it only happens with #5 applied). But this is an issue common to all Go repos which have `vendor` directories...

@wking > This makes less sense to me than having a symlink-less Go tree which ~/src/opencontainers, etc. link into (to make cd'ing in easier, see my cdcwd alias [1]). I...

@wking If you want I can switch to using `GOPATH=vendor go build ...`. Both of them can work (and it's hilarious that Go decided to go with an incompatible vendor...

@wking It works if you do something like this (I remember playing with this a while ago, there's some symlink trickery): ``` % ln -sf . vendor/src % ln -sf...

I've been playing with this for a while, it works pretty nice (especially with the CAS PR). I'm going to write a PR after this is merged to use go-mtree.

Okay, so basically the issue is that the symlink handling is quite seriously incorrect. It assumes that all symlink targets are relative to the link name (this is only true...