can we link to the part of layer.md where we actually define base layer?

agree with @jonboulle

On Wed, Sep 14, 2016 at 04:34:51AM -0700, Jonathan Boulle wrote:

can we link to the part of layer.md where we actually define base
layer?

Which part of layer.md is that? The definition seems to be spread
across layer.md fairly evenly to me ;).

https://github.com/opencontainers/image-spec/blob/master/layer.md#initial-root-filesystem

The document does need a rework for clarity

On Thu, Sep 15, 2016 at 09:54:26AM -0700, Jonathan Boulle wrote:

https://github.com/opencontainers/image-spec/blob/master/layer.md#initial-root-filesystem

The document does need a rework for clarity

It just was (#255 ;), and I'm fairly happy with the current layout.
The section you reference is a subsection that introduces an empty
base directory. But the media types are discussed in 1, the
preserved information is discussed in 2, creating is discussed in
3, etc. I think all of those are important parts of the layer
definition.

There's nothing special about layers[0] vs. the other layers. We just
need to clarify that the layer stack sits on top of an implicit empty
directory (I've suggested wording in 4). And maybe point out that
ownership, permissions, etc. of that base directory are either
unspecified or implementation-defined (previous discussion of ./ in
layer tarballs 5).

@wking I'm lost, can you just put up an alternative PR to this one with your suggestion please? my point is that "The array MUST have the base layer at index 0." currently has just about no meaning.

On Fri, Sep 16, 2016 at 09:34:48AM -0700, Jonathan Boulle wrote:

@wking I'm lost, can you just put up an alternative PR to this one
with your suggestion please?

Done with #318.

my point is that "The array MUST have the base layer at index 0."
currently has just about no meaning.

Agreed, and I also agree with your “we should allow empty layers[]
because it's easy to do, and leave it up to users to decide if it
makes sense or not” (paraphrased from 1). Both #313 and the #318
wording remove that restriction.

I think this is being better addressed in #318