Gentoo Archives: gentoo-portage-dev

From: "W. Trevor King" <wking@×××××××.us>
To: gentoo-portage-dev@l.g.o
Subject: [gentoo-portage-dev] Re: layout.conf: What's our opinion?
Date: Tue, 21 Jan 2014 02:36:21
In Reply to: [gentoo-portage-dev] layout.conf: What's our opinion? by Sebastian Luther
1 On Mon, Jan 20, 2014 at 12:05:30PM +0100, Sebastian Luther wrote:
2 > Currently layout.conf is not under PMS control. This basically means
3 > that every PM (or version thereof) may support different keys and
4 > assign different meanings to them.
6 Standardizing in the PMS sounds like a good idea, for situations where
7 a consensus can be reached.
9 > Portage's behavior for unknown keys in layout.conf is to ignore them
10 > without a warning.
12 That makes sense, and is a good practice for forwards-compatibility
13 [1]. Repositories providing custom keys (or package managers
14 supporting custom keys) do so with the understanding that there may be
15 incompatibilities. Namespaced custom keys (portage-eclass-masters?)
16 would help avoid accidental collision. Versioning the layout.conf key
17 spec would also be useful, so a PM in strict-mode could warn “unknown
18 keys x, y, and z in a v1.2 layout.conf. I only understand v1.0, and
19 it's possible that these keys have been added in subsequent versions”.
21 > The bad thing about this is that some layout.conf keys portage
22 > currently supports, may render the repository unusable for a PM if
23 > it doesn't support them.
25 Can you give an example of the breakage? Maybe I just haven't been
26 listening in the right places. If the problem is that the
27 repositories *need* a custom key that is not universally supported,
28 then that seems like something the repository authors should expect.
30 > After discussing this one IRC I came to the conclusion that we just
31 > disagree on how we should handle additions to layout.conf.
32 >
33 > Basically it's either
34 > 1) "We add things as we see fit." or
35 > 2) "We should only add things if absolutely necessary.".
37 Locking everything down completely seems overly harsh, and makes it
38 harder to experiment with new features. Why not:
40 1.5) We can add custom keys as we see fit under the ‘portage-*’
41 namespace.
43 * Portable repositories should not rely on them until they land
44 in the PMS under a new layout.conf version, at which time the
45 ‘portage-’ prefix will be removed.
47 * Portage will recognize any newly standardized keys under their
48 old ‘portage-*’ name to allow repositories to gracefully
49 transition to the standardized names.
51 Cheers,
52 Trevor
54 [1]:
56 --
57 This email may be signed or encrypted with GnuPG (
58 For more information, see


File name MIME type
signature.asc application/pgp-signature