On Mon, Jan 20, 2014 at 12:05:30PM +0100, Sebastian Luther wrote:
> Currently layout.conf is not under PMS control. This basically means
> that every PM (or version thereof) may support different keys and
> assign different meanings to them.

Standardizing in the PMS sounds like a good idea, for situations where
a consensus can be reached.

> Portage's behavior for unknown keys in layout.conf is to ignore them
> without a warning.

That makes sense, and is a good practice for forwards-compatibility
[1].  Repositories providing custom keys (or package managers
supporting custom keys) do so with the understanding that there may be
incompatibilities.  Namespaced custom keys (portage-eclass-masters?)
would help avoid accidental collision.  Versioning the layout.conf key
spec would also be useful, so a PM in strict-mode could warn “unknown
keys x, y, and z in a v1.2 layout.conf.  I only understand v1.0, and
it's possible that these keys have been added in subsequent versions”.

> The bad thing about this is that some layout.conf keys portage
> currently supports, may render the repository unusable for a PM if
> it doesn't support them.

Can you give an example of the breakage?  Maybe I just haven't been
listening in the right places.  If the problem is that the
repositories *need* a custom key that is not universally supported,
then that seems like something the repository authors should expect.

> After discussing this one IRC I came to the conclusion that we just
> disagree on how we should handle additions to layout.conf.
> 
> Basically it's either
> 1) "We add things as we see fit." or
> 2) "We should only add things if absolutely necessary.".

Locking everything down completely seems overly harsh, and makes it
harder to experiment with new features.  Why not:

1.5) We can add custom keys as we see fit under the ‘portage-*’
     namespace.

     * Portable repositories should not rely on them until they land
       in the PMS under a new layout.conf version, at which time the
       ‘portage-’ prefix will be removed.

     * Portage will recognize any newly standardized keys under their
       old ‘portage-*’ name to allow repositories to gracefully
       transition to the standardized names.

Cheers,
Trevor

[1]: http://www.w3.org/2001/tag/doc/versioning-20070326.html#iddiv470454016

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy