| 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. |
| 5 |
|
| 6 |
Standardizing in the PMS sounds like a good idea, for situations where |
| 7 |
a consensus can be reached. |
| 8 |
|
| 9 |
> Portage's behavior for unknown keys in layout.conf is to ignore them |
| 10 |
> without a warning. |
| 11 |
|
| 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”. |
| 20 |
|
| 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. |
| 24 |
|
| 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. |
| 29 |
|
| 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.". |
| 36 |
|
| 37 |
Locking everything down completely seems overly harsh, and makes it |
| 38 |
harder to experiment with new features. Why not: |
| 39 |
|
| 40 |
1.5) We can add custom keys as we see fit under the ‘portage-*’ |
| 41 |
namespace. |
| 42 |
|
| 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. |
| 46 |
|
| 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. |
| 50 |
|
| 51 |
Cheers, |
| 52 |
Trevor |
| 53 |
|
| 54 |
[1]: http://www.w3.org/2001/tag/doc/versioning-20070326.html#iddiv470454016 |
| 55 |
|
| 56 |
-- |
| 57 |
This email may be signed or encrypted with GnuPG (http://www.gnupg.org). |
| 58 |
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy |
Archives