1 |
El jue, 05-07-2007 a las 15:53 +0300, Philipp Riegger escribió: |
2 |
> Hi! |
3 |
> |
4 |
> I wanted to send the patches for gnap i made so far. I don't know what i |
5 |
> screwed up, but somehow they do not apply cleanly. I send them anyway for |
6 |
> review, if anybody wants i can send my current gnap_* scripts or recreate |
7 |
> working patches. |
8 |
|
9 |
kingtaco told me infra have the new machine, so i hope to have our new |
10 |
home soon, so all of us can use the repo to work together and fast. |
11 |
|
12 |
> I will send the patcehs as replies to this email (since they are mostly |
13 |
> for review). |
14 |
|
15 |
i will review them soon as possible, so can be great jaervousz and the |
16 |
resto do it too. |
17 |
|
18 |
> 01-split-gnap_make.patch |
19 |
> 02-split-gnap_overlay.patch |
20 |
> 03-split-gnap_remaster.patch |
21 |
> |
22 |
> Theese first 3 patches take the common stuff (functions, constants) from |
23 |
> the gnap_* scripts and put it into gnap_shared.sh |
24 |
> |
25 |
> Note: |
26 |
> 1) There are 2 gnap_shared.sh so far, one in the src and one in the toos |
27 |
> directory of the gnap svn tree. This should maybe be changed... |
28 |
|
29 |
shoudl be |
30 |
|
31 |
> 2) The gnap_* scripts do 'source "gnap_shared.sh"', which is probably not |
32 |
> good. In which directory will we put gnap_shared.sh? |
33 |
|
34 |
at moment "/usr/lib/gnap" |
35 |
|
36 |
[...] |
37 |
|
38 |
> 08-namespace-gnap_shared.patch |
39 |
> |
40 |
> This cleanes up the namespace, all variables that are used as input |
41 |
> parameters in gnap_shared.sh are prefixed with GNAP_ to get a clean usage |
42 |
> of the namespace. More to that later. |
43 |
|
44 |
great |
45 |
|
46 |
[...] |
47 |
|
48 |
> Ok, so far, so good. What's next? |
49 |
> |
50 |
> 1) Configuring gnap |
51 |
> |
52 |
> At the moment configuring gnap_make (at which i concentrate so far) is |
53 |
> quite a mess. We have default parameters (in gnap_shared.sh), we have |
54 |
> catalyst.conf and commons.conf which we simply source, we have command |
55 |
> line options. At the moment this means the following: |
56 |
> |
57 |
> Default options are set first, then they are overwritten by command line |
58 |
> options, which are overwritten by common.conf, ehich are overwritten by |
59 |
> catalyst.conf. |
60 |
> |
61 |
> This is not really clean. For example, we use CATALYST_TEMP_DIR in |
62 |
> common.conf, catalyst uses store_dir in catalyst.conf. This is redundant |
63 |
> and does not make it clean. The default common.conf also defines |
64 |
> CATALYST_CONF (which might be broken because i renamed it, i have to |
65 |
> check), but that means that the command line option for specifying |
66 |
> catalyst.conf does not work if this is not commented out. |
67 |
> |
68 |
> So... do we want to change this? I would like something like: |
69 |
> |
70 |
> We can use variables from the environment. This will only be valid for |
71 |
> GNAP_* variables, so we have a clear namespace and it enables people to |
72 |
> set default variables. I'm not sure, how much this will be needed/used, |
73 |
> but it sounds like an interesting feature. The catalyst.conf is only used |
74 |
> for catalyst configuration (interaction between gnap and catalyst), |
75 |
> therefore it does never make sense to overwrite information given there. |
76 |
> |
77 |
> Default options < environment < common.conf < command line options. |
78 |
> |
79 |
> This would be my prefered way of configuring gnap, where variables from |
80 |
> sources more right overwrite variables from sources more left. |
81 |
|
82 |
i like the idea, work on it and tell me. I prefer as less config files |
83 |
to edit better. |
84 |
|
85 |
> 2) gnap_make feature: pretend |
86 |
> |
87 |
> I'd like a --pretend feature for gnap_make which lets it just create the |
88 |
> configuration files for catalyst and the source files (portage tree, from |
89 |
> tree snapsht and overlays). This might be useful for test runs, |
90 |
> development and usage of catalyst features gnap does not support. This |
91 |
> could be implemented by simply overwriting CATALYST_BIN with "echo |
92 |
> $CATALYSY_BIN", if 1) from above is clear. |
93 |
|
94 |
i prefer to mantain gnap simple as possible, Really some catalyst option |
95 |
is so usefull to use it alone? non-implemented-catalyst options are |
96 |
sufficent usefull to implement them in gnap_make? |
97 |
|
98 |
> 3) gnap_make feature: improved overlay handling |
99 |
> |
100 |
> The overlay handling of gnap_make is some kind of bug, i think. If you |
101 |
> don't take care, Manifests are broken. Therefore i want to change it that |
102 |
> packages (directories in which ebuilds are) are first deleted from the |
103 |
> tree and metadata/cache if they exist, before new ones from overlays are |
104 |
> added. This should be easy to understand, since people usually don't need |
105 |
> stuff from the tree anymore if they use an overlay for a specific package. |
106 |
|
107 |
To improve is ever good :) |
108 |
|
109 |
> 4) some small stuff |
110 |
> |
111 |
> At the moment, if there is a choice (Overwrite/Append, Yes/No) only one |
112 |
> possibility is checked and the other is assumed, if the one is not given. |
113 |
> I'd like to change this to something like "It is asked in a loop until a |
114 |
> valid option is given." |
115 |
> |
116 |
> There is a function gwarn, writes to stderr. It is used in some places |
117 |
> where ginfo would make more sence, if it would exist. I'd like to |
118 |
> implement and use this. |
119 |
|
120 |
for example? |
121 |
|
122 |
> That's all i wanted to say about the gnap_scripts at the moment. |
123 |
|
124 |
you say a lot :) |
125 |
|
126 |
nice job |
127 |
|
128 |
-- |
129 |
gnap-dev@g.o mailing list |