1 |
josé Alberto Suárez López wrote: |
2 |
|
3 |
> kingtaco told me infra have the new machine, so i hope to have our new |
4 |
> home soon, so all of us can use the repo to work together and fast. |
5 |
|
6 |
Nice. With this change, are you also switching to svn or soemthing like |
7 |
that or changing the gnap repository layout? Making a difference between |
8 |
gnap_make and the other scripts seems rather artificial, since they are |
9 |
sharing code now. |
10 |
|
11 |
>> Note: |
12 |
>> 1) There are 2 gnap_shared.sh so far, one in the src and one in the toos |
13 |
>> directory of the gnap svn tree. This should maybe be changed... |
14 |
> |
15 |
> shoudl be |
16 |
|
17 |
Where do you want to have it? |
18 |
|
19 |
>> 2) The gnap_* scripts do 'source "gnap_shared.sh"', which is probably |
20 |
>> not |
21 |
>> good. In which directory will we put gnap_shared.sh? |
22 |
> |
23 |
> at moment "/usr/lib/gnap" |
24 |
|
25 |
Seems to make the most sense, i'll change that. |
26 |
|
27 |
>> 08-namespace-gnap_shared.patch |
28 |
>> |
29 |
>> This cleanes up the namespace, all variables that are used as input |
30 |
>> parameters in gnap_shared.sh are prefixed with GNAP_ to get a clean |
31 |
>> usage |
32 |
>> of the namespace. More to that later. |
33 |
> |
34 |
> great |
35 |
|
36 |
It's not 100% clean so far, i did not work on variables in gnap_overlay |
37 |
and gnap_remaster so far, i also forgot to check which implications this |
38 |
has on the config files. |
39 |
|
40 |
>> Ok, so far, so good. What's next? |
41 |
>> |
42 |
>> 1) Configuring gnap |
43 |
>> |
44 |
>> At the moment configuring gnap_make (at which i concentrate so far) is |
45 |
>> quite a mess. We have default parameters (in gnap_shared.sh), we have |
46 |
>> catalyst.conf and commons.conf which we simply source, we have command |
47 |
>> line options. At the moment this means the following: |
48 |
>> |
49 |
>> Default options are set first, then they are overwritten by command line |
50 |
>> options, which are overwritten by common.conf, ehich are overwritten by |
51 |
>> catalyst.conf. |
52 |
>> |
53 |
>> This is not really clean. For example, we use CATALYST_TEMP_DIR in |
54 |
>> common.conf, catalyst uses store_dir in catalyst.conf. This is redundant |
55 |
>> and does not make it clean. The default common.conf also defines |
56 |
>> CATALYST_CONF (which might be broken because i renamed it, i have to |
57 |
>> check), but that means that the command line option for specifying |
58 |
>> catalyst.conf does not work if this is not commented out. |
59 |
>> |
60 |
>> So... do we want to change this? I would like something like: |
61 |
>> |
62 |
>> We can use variables from the environment. This will only be valid for |
63 |
>> GNAP_* variables, so we have a clear namespace and it enables people to |
64 |
>> set default variables. I'm not sure, how much this will be needed/used, |
65 |
>> but it sounds like an interesting feature. The catalyst.conf is only |
66 |
>> used |
67 |
>> for catalyst configuration (interaction between gnap and catalyst), |
68 |
>> therefore it does never make sense to overwrite information given there. |
69 |
>> |
70 |
>> Default options < environment < common.conf < command line options. |
71 |
>> |
72 |
>> This would be my prefered way of configuring gnap, where variables from |
73 |
>> sources more right overwrite variables from sources more left. |
74 |
> |
75 |
> i like the idea, work on it and tell me. I prefer as less config files |
76 |
> to edit better. |
77 |
|
78 |
The easiest way to implement this would be: |
79 |
|
80 |
We use ${:-} or ${:=} (i have to understand the difference between them) |
81 |
for default parameters, parse the command line for the first time only |
82 |
extracting parameters concerning external config files or -h, parse theese |
83 |
config files (we have them or default config files), order will be |
84 |
common.conf and then catalyst.conf (so common.conf can overwrite the |
85 |
variable saying where to find catalyst.conf), we parse the command line |
86 |
options again and use all the info given there to set/overwrite variables. |
87 |
|
88 |
Advantages: |
89 |
- No additional variables needed |
90 |
- Quite easy change |
91 |
- Should give us what we want |
92 |
- No need for a config file parser |
93 |
|
94 |
Disadvantages: |
95 |
- Well... common.conf and catalyst.conf can overwrite lots of things, we |
96 |
never check which config file is allowed to overwrite what. But if |
97 |
somebody does strange things there, it's not our fault, i think |
98 |
|
99 |
|
100 |
>> 2) gnap_make feature: pretend |
101 |
>> |
102 |
>> I'd like a --pretend feature for gnap_make which lets it just create the |
103 |
>> configuration files for catalyst and the source files (portage tree, |
104 |
>> from |
105 |
>> tree snapsht and overlays). This might be useful for test runs, |
106 |
>> development and usage of catalyst features gnap does not support. This |
107 |
>> could be implemented by simply overwriting CATALYST_BIN with "echo |
108 |
>> $CATALYSY_BIN", if 1) from above is clear. |
109 |
> |
110 |
> i prefer to mantain gnap simple as possible, Really some catalyst option |
111 |
> is so usefull to use it alone? non-implemented-catalyst options are |
112 |
> sufficent usefull to implement them in gnap_make? |
113 |
|
114 |
Hmm, all the reasons why i thought this might be a good idea are only |
115 |
minor. So... i'll move that off my todo list until i find a valid use case |
116 |
for it. |
117 |
|
118 |
>> 3) gnap_make feature: improved overlay handling |
119 |
|
120 |
[...] |
121 |
|
122 |
> To improve is ever good :) |
123 |
|
124 |
An alternative would be to introduce overlay handling to catalyst, but i |
125 |
think, we don't want that. :-) |
126 |
|
127 |
>> 4) some small stuff |
128 |
>> |
129 |
>> At the moment, if there is a choice (Overwrite/Append, Yes/No) only one |
130 |
>> possibility is checked and the other is assumed, if the one is not |
131 |
>> given. |
132 |
>> I'd like to change this to something like "It is asked in a loop until a |
133 |
>> valid option is given." |
134 |
|
135 |
Any comments on this? |
136 |
|
137 |
Examples: |
138 |
|
139 |
gconfirm() { |
140 |
if [[ "${FORCEYES}" -eq 1 ]]; then |
141 |
gwarn "${*} forced to yes" |
142 |
else |
143 |
read -ep " ${W}*${N} ${*} [N]: " answer |
144 |
if [[ "${answer}" != 'y' && "${answer}" != 'Y' ]]; then |
145 |
if [[ -n "${GNAP_TEMPDIR}" ]]; then |
146 |
cleanup |
147 |
fi |
148 |
echo "${GNAP_PRODUCT} aborted !" |
149 |
exit 2 |
150 |
fi |
151 |
fi |
152 |
} |
153 |
|
154 |
what if the user mixes up for example german and us keyboard layout, wants |
155 |
to say y but gets z instead? |
156 |
|
157 |
if [[ -f "${GNAP_LOGPREFIX}.out" || -f "${GNAP_LOGPREFIX}.err" ]]; then |
158 |
if [[ "${FORCEYES}" -ne 1 ]]; then |
159 |
read -ep " ${W}*${N} Logfile(s) already exists. |
160 |
Append/Overwrite |
161 |
[A]: " \ |
162 |
answer |
163 |
if [[ "${answer}" == 'o' || "${answer}" == 'O' ]]; then |
164 |
rm "${GNAP_LOGPREFIX}.out" "${GNAP_LOGPREFIX}.err" |
165 |
fi |
166 |
fi |
167 |
fi |
168 |
|
169 |
Same here, i cannot think of keymap issues but peope sometimes hit the |
170 |
wrong button. Should we have the questions in a loop until they are |
171 |
answered correctly? |
172 |
|
173 |
>> There is a function gwarn, writes to stderr. It is used in some places |
174 |
>> where ginfo would make more sence, if it would exist. I'd like to |
175 |
>> implement and use this. |
176 |
> |
177 |
> for example? |
178 |
|
179 |
gwarn 'The following targets will be called:' |
180 |
gwarn "${TARGETLIST}" |
181 |
|
182 |
>> That's all i wanted to say about the gnap_scripts at the moment. |
183 |
> |
184 |
> you say a lot :) |
185 |
|
186 |
Hmm... is that good or bad? :) |
187 |
|
188 |
> nice job |
189 |
|
190 |
Thanks, unfortunately not what i applied for. :-( |
191 |
|
192 |
See you, |
193 |
Philipp |
194 |
-- |
195 |
gnap-dev@g.o mailing list |