public inbox for gentoo-portage-dev@lists.gentoo.org
 help / color / mirror / Atom feed
Search results ordered by [date|relevance]  view[summary|nested|Atom feed]
thread overview below | download: 
* [gentoo-portage-dev] Re: layout.conf: What's our opinion?
  @ 2014-01-21  2:36 99% ` W. Trevor King
  0 siblings, 0 replies; 1+ results
From: W. Trevor King @ 2014-01-21  2:36 UTC (permalink / raw
  To: gentoo-portage-dev

[-- Attachment #1: Type: text/plain, Size: 2552 bytes --]

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[relevance 99%]

Results 1-1 of 1 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2014-01-20 11:05     [gentoo-portage-dev] layout.conf: What's our opinion? Sebastian Luther
2014-01-21  2:36 99% ` [gentoo-portage-dev] " W. Trevor King

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox