1 |
<?xml version="1.0" encoding="utf-8" ?> |
2 |
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> |
3 |
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> |
4 |
<!-- |
5 |
This HTML is auto-generated. DO NOT EDIT THIS FILE! If you are writing a new |
6 |
PEP, see http://www.python.org/peps/pep-0001.html for instructions and links |
7 |
to templates. DO NOT USE THIS HTML FILE AS YOUR TEMPLATE! |
8 |
--> |
9 |
<head> |
10 |
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> |
11 |
<meta name="generator" content="Docutils 0.3.5: http://docutils.sourceforge.net/" /> |
12 |
<title>GLEP 35 -- Automated consistency check for ebuilds</title> |
13 |
<link rel="stylesheet" href="tools/glep.css" type="text/css" /> |
14 |
</head> |
15 |
<body bgcolor="white"> |
16 |
<table class="navigation" cellpadding="0" cellspacing="0" |
17 |
width="100%" border="0"> |
18 |
<tr><td class="navicon" width="150" height="35"> |
19 |
<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page"> |
20 |
<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]" |
21 |
border="0" width="150" height="35" /></a></td> |
22 |
<td class="textlinks" align="left"> |
23 |
[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>] |
24 |
[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>] |
25 |
[<b><a href="./glep-0035.txt">GLEP Source</a></b>] |
26 |
</td></tr></table> |
27 |
<div class="document"> |
28 |
<table class="rfc2822 field-list" frame="void" rules="none"> |
29 |
<col class="field-name" /> |
30 |
<col class="field-body" /> |
31 |
<tbody valign="top"> |
32 |
<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">35</td> |
33 |
</tr> |
34 |
<tr class="field"><th class="field-name">Title:</th><td class="field-body">Automated consistency check for ebuilds</td> |
35 |
</tr> |
36 |
<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.1</td> |
37 |
</tr> |
38 |
<tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference" href="http://www.gentoo.org/cgi-bin/viewcvs/xml/htdocs/proj/en/glep/glep-0035.txt?cvsroot=gentoo">2005/03/12 20:26:01</a></td> |
39 |
</tr> |
40 |
<tr class="field"><th class="field-name">Author:</th><td class="field-body">Adrian Lambeck <adrian at basicsedv.de>,</td> |
41 |
</tr> |
42 |
<tr class="field"><th class="field-name">Status:</th><td class="field-body">Draft</td> |
43 |
</tr> |
44 |
<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td> |
45 |
</tr> |
46 |
<tr class="field"><th class="field-name">Content-Type:</th><td class="field-body"><a class="reference" href="glep-0012.html">text/x-rst</a></td> |
47 |
</tr> |
48 |
<tr class="field"><th class="field-name">Created:</th><td class="field-body">12-Mar-2005</td> |
49 |
</tr> |
50 |
<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">12-Mar-2005</td> |
51 |
</tr> |
52 |
</tbody> |
53 |
</table> |
54 |
<hr /> |
55 |
<div class="contents topic" id="contents"> |
56 |
<p class="topic-title first"><a name="contents">Contents</a></p> |
57 |
<ul class="simple"> |
58 |
<li><a class="reference" href="#abstract" id="id5" name="id5">Abstract</a></li> |
59 |
<li><a class="reference" href="#motivation" id="id6" name="id6">Motivation</a></li> |
60 |
<li><a class="reference" href="#specification" id="id7" name="id7">Specification</a></li> |
61 |
<li><a class="reference" href="#implementation" id="id8" name="id8">Implementation</a></li> |
62 |
<li><a class="reference" href="#backwards-compatibility" id="id9" name="id9">Backwards Compatibility</a></li> |
63 |
<li><a class="reference" href="#id1" id="id10" name="id10">References</a></li> |
64 |
</ul> |
65 |
</div> |
66 |
<div class="section" id="abstract"> |
67 |
<h1><a class="toc-backref" href="#id5" name="abstract">Abstract</a></h1> |
68 |
<p>This proposal is meant to enhance productivity for Gentoo developers. |
69 |
It aims to reduce the number of trivial bugs by automatically detecting them |
70 |
through a consistency check that is performed before checking and on a regular |
71 |
basis through the whole tree. |
72 |
Why bother with trivial bugs when automated tests find them ? |
73 |
Save time and improve quality !</p> |
74 |
</div> |
75 |
<div class="section" id="motivation"> |
76 |
<h1><a class="toc-backref" href="#id6" name="motivation">Motivation</a></h1> |
77 |
<p>When browsing <a class="reference" href="http://bugs.gentoo.org">bugs.gentoo.org</a> <a class="footnote-reference" href="#id2" id="id3" name="id3">[1]</a> you will find Bugs that take away a good |
78 |
amount of scarce developing time that could be used otherwise. These are |
79 |
trivial bugs, i.e. wrong SRC_URI or cycles in DEPEND. Even worst - these bugs |
80 |
are sometimes reported several times so that they need to be marked as |
81 |
dublicates. Bugs of that kind are easy to find and easy to fix. By using |
82 |
automatic checks on a regular schedule these bugs can be found. Users have to |
83 |
be asked NOT to commit these bugs to <a class="reference" href="http://bugs.gentoo.org">bugs.gentoo.org</a> <a class="footnote-reference" href="#id2" id="id4" name="id4">[1]</a>. So there will |
84 |
(hopefully) be fewer bugs that need to be checked and assigned and they might |
85 |
get fixed faster.</p> |
86 |
<p>The Bugs found should be kept in an automatically generated list so that users |
87 |
can see that the problem has been caught and that it is being worked on.</p> |
88 |
</div> |
89 |
<div class="section" id="specification"> |
90 |
<h1><a class="toc-backref" href="#id7" name="specification">Specification</a></h1> |
91 |
<p>Checks need to be performed for every ebuild.</p> |
92 |
<p>A report needs to be generated</p> |
93 |
<blockquote> |
94 |
<ul class="simple"> |
95 |
<li>links to the specific problem need to be included</li> |
96 |
<li>reports need to be send to the groups responsible</li> |
97 |
</ul> |
98 |
</blockquote> |
99 |
<p>Checks could be:</p> |
100 |
<blockquote> |
101 |
<ul class="simple"> |
102 |
<li>cycles within DEPEND</li> |
103 |
<li>invalid SRC_URI</li> |
104 |
<li>"non-official" USE Flags</li> |
105 |
<li>Packages within DEPEND that are "*" for the arch specified</li> |
106 |
<li>broken shell scripts with invalid or missing commands</li> |
107 |
<li>inheritance of eclasses</li> |
108 |
<li>...</li> |
109 |
</ul> |
110 |
</blockquote> |
111 |
<p>There might be other checks and tests that should be run |
112 |
that have not come to my mind yet. Also I might have suggested something that |
113 |
is not useful at all.</p> |
114 |
<p>If there are major problems (needs to be defined) within an ebuild a possible |
115 |
action could be to disable the ebuild (with <tt class="literal"><span class="pre">"-*"</span></tt>,) perhaps, and send a |
116 |
mail to the maintainer.</p> |
117 |
<p>These kind of errors are not always the fault of the developers.</p> |
118 |
<p>There should be no compilation or something like that. If an ebuild fails to |
119 |
build somewhere then the user should file it as a bug as usual.</p> |
120 |
</div> |
121 |
<div class="section" id="implementation"> |
122 |
<h1><a class="toc-backref" href="#id8" name="implementation">Implementation</a></h1> |
123 |
<p>The functionality described could be implemented in three ways:</p> |
124 |
<blockquote> |
125 |
<ol class="arabic"> |
126 |
<li><dl class="first"> |
127 |
<dt>On the developers machine ("client") where it is run before checking</dt> |
128 |
<dd><p class="first last">only for the ebuilds that changed. (client does not fit here because |
129 |
the server and client should not communicate with each other at all)</p> |
130 |
</dd> |
131 |
</dl> |
132 |
</li> |
133 |
<li><p class="first">On the server where checks are run, i.e. once a week.</p> |
134 |
</li> |
135 |
<li><p class="first">On the "client" AND server</p> |
136 |
</li> |
137 |
</ol> |
138 |
<p>Of course there are cons and pros (what came to my mind so far)</p> |
139 |
<ol class="arabic"> |
140 |
<li><blockquote class="first"> |
141 |
<dl> |
142 |
<dt>pro: </dt> |
143 |
<dd><ul class="first last simple"> |
144 |
<li>the tree can not become inconsistent in the first place (? see contra)</li> |
145 |
<li>once an ebuild is checked there is no need to do this again</li> |
146 |
<li>no dedicated machine necessary</li> |
147 |
<li>generate traffic only once on one machine</li> |
148 |
<li>errors that are caught here do not bother later on</li> |
149 |
</ul> |
150 |
</dd> |
151 |
<dt>contra:</dt> |
152 |
<dd><ul class="first last"> |
153 |
<li><dl class="first"> |
154 |
<dt>the consistency is based on the tool installed </dt> |
155 |
<dd><p class="first last">(what happens when different devs use different versions ?)</p> |
156 |
</dd> |
157 |
</dl> |
158 |
</li> |
159 |
<li><dl class="first"> |
160 |
<dt>what happens when the ebuild layout changes and some ebuilds</dt> |
161 |
<dd><p class="first last">do not get updated ?</p> |
162 |
</dd> |
163 |
</dl> |
164 |
</li> |
165 |
</ul> |
166 |
</dd> |
167 |
</dl> |
168 |
</blockquote> |
169 |
</li> |
170 |
<li><blockquote class="first"> |
171 |
<dl> |
172 |
<dt>pro:</dt> |
173 |
<dd><ul class="first last simple"> |
174 |
<li>Properties of other ebuilds might change that fit while writing an ebuild</li> |
175 |
</ul> |
176 |
</dd> |
177 |
<dt>contra:</dt> |
178 |
<dd><ul class="first last"> |
179 |
<li><p class="first">the errors are found when the ebuild is already in CVS</p> |
180 |
</li> |
181 |
<li><p class="first">the whole tree needs to be checked</p> |
182 |
</li> |
183 |
<li><dl class="first"> |
184 |
<dt>possibly creates a lot of traffic on every run</dt> |
185 |
<dd><p class="first last">(-> is there an FTP equivalent to HTTP`s HEAD ?)</p> |
186 |
</dd> |
187 |
</dl> |
188 |
</li> |
189 |
</ul> |
190 |
</dd> |
191 |
</dl> |
192 |
</blockquote> |
193 |
</li> |
194 |
<li><p class="first">see 1. and 2.</p> |
195 |
</li> |
196 |
</ol> |
197 |
</blockquote> |
198 |
<p>My favorite is 3 . All properties are checked before check-in and |
199 |
the properties that change might be checked on a regular basis on the server. |
200 |
Only solution 3 brings the best from 1 and 2 together while delivering the best result.</p> |
201 |
<p>I never had a look at portage source but I can imagine that there is a library |
202 |
that has everything that a developer needs to "query" ebuilds. If not, this |
203 |
would be a reason for another GLEP (?).</p> |
204 |
<p>For performance I would use a database (on the server) to store the whole tree before |
205 |
running the checks. This is not necessary for the "client".</p> |
206 |
</div> |
207 |
<div class="section" id="backwards-compatibility"> |
208 |
<h1><a class="toc-backref" href="#id9" name="backwards-compatibility">Backwards Compatibility</a></h1> |
209 |
<p>Not a problem for this GLEP.</p> |
210 |
</div> |
211 |
<div class="section" id="id1"> |
212 |
<h1><a class="toc-backref" href="#id10" name="id1">References</a></h1> |
213 |
<table class="footnote" frame="void" id="id2" rules="none"> |
214 |
<colgroup><col class="label" /><col /></colgroup> |
215 |
<tbody valign="top"> |
216 |
<tr><td class="label"><a name="id2">[1]</a></td><td><em>(<a class="fn-backref" href="#id3">1</a>, <a class="fn-backref" href="#id4">2</a>)</em> <a class="reference" href="http://bugs.gentoo.org">http://bugs.gentoo.org</a></td></tr> |
217 |
</tbody> |
218 |
</table> |
219 |
</div> |
220 |
</div> |
221 |
|
222 |
<hr class="footer" /> |
223 |
<div class="footer"> |
224 |
<a class="reference" href="glep-0035.txt">View document source</a>. |
225 |
Generated on: 2005-03-12 20:26 UTC. |
226 |
Generated by <a class="reference" href="http://docutils.sourceforge.net/">Docutils</a> from <a class="reference" href="http://docutils.sourceforge.net/rst.html">reStructuredText</a> source. |
227 |
</div> |
228 |
</body> |
229 |
</html> |
230 |
|