Config data types are tied to the build platform

[aaronlehmann]

It's currently not possible to use the specs library to manipulate a Linux container configuration on a different platform, because some of the data types are defined in config_linux.go and runtime_config_linux.go. As a result, the package doesn't even compile on non-Linux platforms:

# github.com/opencontainers/specs
./config.go:26: undefined: User

Varying the data types based on the build target platform doesn't seem like the right approach. It should be possible for a non-architecture-specific tool or client to parse or generate configurations for containers that will eventually run on Linux.

The current approach is also problematic for projects which vendor github.com/opencontainers/specs but still need to support other platforms.

[vbatts]

Thanks for the issue. This has been an issue and discussed. I need to dust
off my PR for this.

On Fri, Feb 19, 2016 at 2:04 PM Aaron Lehmann notifications@github.com
wrote:

It's currently not possible to use the specs library to manipulate a Linux
container configuration on a different platform, because some of the data
types are defined in config_linux.go and runtime_config_linux.go. As a
result, the package doesn't even compile on non-Linux platforms:

github.com/opencontainers/specs

./config.go:26: undefined: User

Varying the data types based on the build target platform doesn't seem
like the right approach. It should be possible for a
non-architecture-specific tool or client to parse or generate
configurations for containers that will eventually run on Linux.

The current approach is also problematic for projects which vendor
github.com/opencontainers/specs but still need to support other platforms.

—
Reply to this email directly or view it on GitHub
#324.

[wking]

On Fri, Feb 19, 2016 at 11:48:54AM -0800, Vincent Batts wrote:

This has been an issue and discussed.

Previous issues are #135 and #166. Close this one in favor of #166?

[vbatts]

closing in favor of #166