1 |
Hi all, |
2 |
|
3 |
${repository}/metadata/layout.conf is a file that allows a repository |
4 |
maintainer to adjust the package manager's behavior for a repository. |
5 |
I guess the best known is the 'masters' key, but there are lots of other |
6 |
things by now (see man portage). |
7 |
|
8 |
Currently layout.conf is not under PMS control. This basically means |
9 |
that every PM (or version thereof) may support different keys and assign |
10 |
different meanings to them. Portage's behavior for unknown keys in |
11 |
layout.conf is to ignore them without a warning. |
12 |
|
13 |
The bad thing about this is that some layout.conf keys portage currently |
14 |
supports, may render the repository unusable for a PM if it doesn't |
15 |
support them. |
16 |
|
17 |
To avoid this type of breakage in other areas (ebuilds, dependency |
18 |
resolution, ...) PMS has been created. Since the council demands PMS to |
19 |
be followed, I would expect that they also want the general idea "of not |
20 |
breaking things randomly" to be followed. |
21 |
|
22 |
This brings us to reason that made me write that mail. Some days ago |
23 |
Arfrever committed some additions to layout.conf [1], for which he |
24 |
apparently had the ack from Zac from some months ago [2]. |
25 |
|
26 |
After discussing this one IRC I came to the conclusion that we just |
27 |
disagree on how we should handle additions to layout.conf. |
28 |
|
29 |
Basically it's either |
30 |
1) "We add things as we see fit." or |
31 |
2) "We should only add things if absolutely necessary.". |
32 |
|
33 |
I obviously would prefer 2) to follow the "things shouldn't break |
34 |
randomly" route. |
35 |
|
36 |
So what's your opinion? Should we go for 1) or 2) or something else? |
37 |
|
38 |
- Sebastian |
39 |
|
40 |
|
41 |
[1] |
42 |
http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=4c409a049c394389b1de398db511380e2fed0437 |
43 |
|
44 |
[2] http://dpaste.com/1560782/ |