1 |
Adding -dev to CC: in case someone has any meaningful input or has |
2 |
already tackled this problem... |
3 |
|
4 |
On Aug 14, 2005, at 8:21 AM, Grobian wrote: |
5 |
|
6 |
> Introduction |
7 |
> ============ |
8 |
> |
9 |
> Recently, once again we were confronted with a package marked as |
10 |
> ppc-macos stable, while it didn't compile at all, let alone run. |
11 |
> It is |
12 |
> believed more of these packages are in portage, and need to be |
13 |
> found and |
14 |
> fixed. Keeping the cause of why they are marked stable up to another |
15 |
> discussion, and out of the scope of this discussion, I will focus |
16 |
> on how |
17 |
> to track these packages down and report them to us. |
18 |
> |
19 |
> In the secondary line, all 'unstable' packages, marked ~ppc-macos |
20 |
> should |
21 |
> be tested as well, since they can be faulty as well. Since for OSX |
22 |
> much |
23 |
> is in ~ppc-macos, many users consider it a normal procedure to |
24 |
> switch to |
25 |
> the unstable side of portage, hence some extra need for careful |
26 |
> testing |
27 |
> of ~ppc-macos also. |
28 |
> |
29 |
> |
30 |
> Proposed Global Structure |
31 |
> ========================= |
32 |
> |
33 |
> Testing should be done on a regular basis, both push and pull based. |
34 |
> This means that the testing machine would start testing packages |
35 |
> itself |
36 |
> if it is out of work, and on the other hand starts testing packages as |
37 |
> soon as they are being added/changed in CVS. It may need no great |
38 |
> imagination to see that the latter 'push-based' activity has priority |
39 |
> over the 'pull-based' work. |
40 |
|
41 |
I'm not sure direct interaction with CVS would be needed, usually |
42 |
only takes a short time for cvs commits to hit the rsync mirrors |
43 |
(hence the volatile nature of the tree) |
44 |
|
45 |
> |
46 |
> Starting over, will for the test machine mean that it starts cleaning |
47 |
> out its world file. Cleaning this file out to a bare minimum is an |
48 |
> important aspect of getting a test environment that reflects the |
49 |
> situation on new user's machines. If an ebuild uses a package without |
50 |
> having it in it's DEPEND, this may get noticed only when starting on a |
51 |
> clean machine. This, however, will add a big delay in testing as many |
52 |
> packages will need to be built prior the right package can be |
53 |
> installed. |
54 |
> |
55 |
> The testing machine will have a queue file, which it reads packages to |
56 |
> emerge from. If the queue file is empty, i.e. when there is no push |
57 |
> based work, the machine will generate work by starting to compile |
58 |
> uncompiled packages, or emptying the tree. |
59 |
> |
60 |
> Because ~ppc-macos and ppc-macos packages interfere with each other |
61 |
> -- a ~ppc-macos package overwrites a ppc-macos package -- both |
62 |
> stable and unstable have to be dealt with separately, i.e. they |
63 |
> should both have their own environment either via two separate |
64 |
> machines, or through the use of a chroot jail. |
65 |
|
66 |
I think seperate chroots are definitely the way to go. We can just |
67 |
store a 'pristine' chroot in iso or dmg or whatever on the build |
68 |
server and copy when needed. |
69 |
|
70 |
> |
71 |
> |
72 |
> Queues |
73 |
> ------ |
74 |
> |
75 |
> In order not to drag in a full DBMS (in the end Portage already is |
76 |
> one) queues are just simple flat files consisting of absolute |
77 |
> package names, one per line. Table wise locking granularity is |
78 |
> handled by the OS as one process opens the file in write mode. |
79 |
> Consumers -- the testing box in this case -- read the first line |
80 |
> and delete it, while producers simply add one line (or more) to the |
81 |
> end of the file. |
82 |
> |
83 |
> The queue itself, is more a set than a list. This means that |
84 |
> packages that are in the queue, should be unique. If a package is |
85 |
> added that is already in the queue, it is dropped such that the |
86 |
> original queue position of the package is maintained. |
87 |
|
88 |
Maybe a 'proper' dbms wouldn't be such a bad idea, could also store |
89 |
build logs, timestamps, etc. there and make it easier for multiple |
90 |
build hosts to push/pull from a centralized server. |
91 |
|
92 |
> |
93 |
> |
94 |
> CVS Producer |
95 |
> ------------ |
96 |
> |
97 |
> To catch up automatically with changes made to the tree, it is |
98 |
> necessary to act upon any commit to the tree for an ebuild file. A |
99 |
> possibility to do this would be via processing of CVS commit |
100 |
> messages, sent out as email by the CVS server. It is a task of the |
101 |
> producer to find out whether the ebuild found applies to the |
102 |
> testing machine (ppc-macos) and add the package/ebuild to the queue. |
103 |
> |
104 |
> |
105 |
> Consumer (testing process) |
106 |
> -------------------------- |
107 |
> |
108 |
> The test machine reads a line from the queue, and basically |
109 |
> executes 'emerge ${PACKAGE}'. However, before doing this, first it |
110 |
> figures out which use flags can be used (emerge -pv) and which |
111 |
> dependencies will be pulled (emerge -pt). If portage returns the |
112 |
> message all ebuilds that could satisfy X have been masked, the |
113 |
> emerge is cancelled, the line is removed from the queue and an |
114 |
> email message will be sent out. |
115 |
> |
116 |
> All dependencies are put in the right order and emerged as normal |
117 |
> packages, that is: all dependencies are pushed at the front of the |
118 |
> queue, thereby keeping uniqueness of the queue and removing |
119 |
> duplicates that appear later on in the queue. After this, the |
120 |
> consumer is restarted and reads again from the queue. This should |
121 |
> result in usually merging only one package at a time, and as such |
122 |
> quite isolated cases, which should improve the error email |
123 |
> notification service. |
124 |
> |
125 |
> Compile testing a package is supposed to be a thorough test that |
126 |
> tries all possible combinations of the package's USE flags. As |
127 |
> this might be somewhat endless as some packages are rather big and |
128 |
> have zillions of USE flags, it may be necessary to have a special |
129 |
> "don't do it" file. |
130 |
> Since all dependencies were put at the front of the queue, there |
131 |
> should normally be no dependencies that the package pulls. |
132 |
> If compilation fails for a certain USE-flag combination this is |
133 |
> reported by sending out an email, and compilation of the next USE- |
134 |
> flag combination is attempted. |
135 |
> |
136 |
> When everything goes fine, no email notification is being sent |
137 |
> out. A convenient log structure would, however, make it possible |
138 |
> to see which packages and USE-flag combinations successfully passed |
139 |
> through. Providing this log via a web-page would be a useful |
140 |
> thing. Again backing this with a DBMS to allow easy searching, |
141 |
> versioning and stuff is considered to be overhead, though crafting |
142 |
> logs in SQL's "INSERT INTO" format might enable another machine to |
143 |
> display the output data. Perhaps the communication methods needs a |
144 |
> section on itself. |
145 |
> |
146 |
> |
147 |
> Recap and Conclusion |
148 |
> ==================== |
149 |
> |
150 |
> By setting up a testing system, it is possible to greatly improve |
151 |
> the Quality of Service of the portage tree for an architecture by |
152 |
> exhaustive testing of both packages already in there, as well as |
153 |
> packages added or modified. Automated testing should not release |
154 |
> developers from testing themselves, but should help in pointing out |
155 |
> problems that may arise on moving grounds such as portage where |
156 |
> packages are constantly updated and dependencies might get broken. |
157 |
> |
158 |
> |
159 |
> ToDo |
160 |
> ==== |
161 |
> |
162 |
> - Not only check dependencies of the respective package, but also |
163 |
> consider packages that depend on the respective package, thus |
164 |
> rebuilding all packages that depend on the package to check if |
165 |
> anything is broken by the update. |
166 |
> - Is there a gleptomaniac in the room? This would be useful for |
167 |
> x86 also, of course. In that case it may be necessary to make sure |
168 |
> the packages are split over multiple machines. |
169 |
> - The message system needs more customisation options, especially |
170 |
> backing things by a DBMS would allow for many nice bugzilla-like |
171 |
> preferences for email generation as well as web-based versioned |
172 |
> info/report pages |
173 |
> - To make the system even bigger, a central DBMS powered server |
174 |
> might take a leading role and ... {editor note: wait, stop it right |
175 |
> now, you're going too fast right now} |
176 |
> |
177 |
> |
178 |
> By The Way |
179 |
> ========== |
180 |
> |
181 |
> - Kito offers his lil' chico as machine for this automated testing |
182 |
> initiative. |
183 |
> - Comments are welcome, as well as expressions of worry on my |
184 |
> mental state. |
185 |
> - Implementation of described system will need some better |
186 |
> specified system and needs some coding (the dirty work) in some |
187 |
> language... |
188 |
> |
189 |
> |
190 |
> -- |
191 |
> Fabian Groffen |
192 |
> eBuild && Porting |
193 |
> Gentoo for Mac OS X |
194 |
> |
195 |
> -- |
196 |
> gentoo-osx@g.o mailing list |
197 |
> |
198 |
> |
199 |
|
200 |
-- |
201 |
gentoo-osx@g.o mailing list |