Gentoo Archives: gnap-dev

From: "josé Alberto Suárez López" <bass@g.o>
To: gnap-dev@l.g.o
Subject: Re: [gnap-dev] Some patches for gnap
Date: Fri, 06 Jul 2007 07:41:02
Message-Id: 1183707646.27777.15.camel@supercoco
In Reply to: [gnap-dev] Some patches for gnap by Philipp Riegger
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

Replies

Subject Author
Re: [gnap-dev] Some patches for gnap Philipp Riegger <lists@××××××××××××.de>