en/glep/glep-0035.html

<?xml version="1.0" encoding="utf-8" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<!--
This HTML is auto-generated.  DO NOT EDIT THIS FILE!  If you are writing a new
PEP, see http://www.python.org/peps/pep-0001.html for instructions and links
to templates.  DO NOT USE THIS HTML FILE AS YOUR TEMPLATE!
-->
<head>
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
  <meta name="generator" content="Docutils 0.3.5: http://docutils.sourceforge.net/" />
  <title>GLEP 35 -- Automated consistency check for ebuilds</title>
  <link rel="stylesheet" href="tools/glep.css" type="text/css" />
</head>
<body bgcolor="white">
<table class="navigation" cellpadding="0" cellspacing="0"
       width="100%" border="0">
<tr><td class="navicon" width="150" height="35">
<a href="http://www.gentoo.org/" title="Gentoo Linux Home Page">
<img src="http://www.gentoo.org/images/gentoo-new.gif" alt="[Gentoo]"
 border="0" width="150" height="35" /></a></td>
<td class="textlinks" align="left">
[<b><a href="http://www.gentoo.org/">Gentoo Linux Home</a></b>]
[<b><a href="http://www.gentoo.org/proj/en/glep">GLEP Index</a></b>]
[<b><a href="./glep-0035.txt">GLEP Source</a></b>]
</td></tr></table>
<div class="document">
<table class="rfc2822 field-list" frame="void" rules="none">
<col class="field-name" />
<col class="field-body" />
<tbody valign="top">
<tr class="field"><th class="field-name">GLEP:</th><td class="field-body">35</td>
</tr>
<tr class="field"><th class="field-name">Title:</th><td class="field-body">Automated consistency check for ebuilds</td>
</tr>
<tr class="field"><th class="field-name">Version:</th><td class="field-body">1.1</td>
</tr>
<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>
</tr>
<tr class="field"><th class="field-name">Author:</th><td class="field-body">Adrian Lambeck &lt;adrian&#32;&#97;t&#32;basicsedv.de&gt;,</td>
</tr>
<tr class="field"><th class="field-name">Status:</th><td class="field-body">Draft</td>
</tr>
<tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td>
</tr>
<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>
</tr>
<tr class="field"><th class="field-name">Created:</th><td class="field-body">12-Mar-2005</td>
</tr>
<tr class="field"><th class="field-name">Post-History:</th><td class="field-body">12-Mar-2005</td>
</tr>
</tbody>
</table>
<hr />
<div class="contents topic" id="contents">
<p class="topic-title first"><a name="contents">Contents</a></p>
<ul class="simple">
<li><a class="reference" href="#abstract" id="id5" name="id5">Abstract</a></li>
<li><a class="reference" href="#motivation" id="id6" name="id6">Motivation</a></li>
<li><a class="reference" href="#specification" id="id7" name="id7">Specification</a></li>
<li><a class="reference" href="#implementation" id="id8" name="id8">Implementation</a></li>
<li><a class="reference" href="#backwards-compatibility" id="id9" name="id9">Backwards Compatibility</a></li>
<li><a class="reference" href="#id1" id="id10" name="id10">References</a></li>
</ul>
</div>
<div class="section" id="abstract">
<h1><a class="toc-backref" href="#id5" name="abstract">Abstract</a></h1>
<p>This proposal is meant to enhance productivity for Gentoo developers.
It aims to reduce the number of trivial bugs by automatically detecting them
through a consistency check that is performed before checking and on a regular
basis through the whole tree.
Why bother with trivial bugs when automated tests find them ?
Save time and improve quality !</p>
</div>
<div class="section" id="motivation">
<h1><a class="toc-backref" href="#id6" name="motivation">Motivation</a></h1>
<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
amount of scarce developing time that could be used otherwise.  These are
trivial bugs, i.e. wrong SRC_URI or cycles in DEPEND. Even worst - these bugs
are sometimes reported several times so that they need to be marked as
dublicates.  Bugs of that kind are easy to find and easy to fix. By using
automatic checks on a regular schedule these bugs can be found.  Users have to
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
(hopefully) be fewer bugs that need to be checked and assigned and they might
get fixed faster.</p>
<p>The Bugs found should be kept in an automatically generated list so that users
can see that the problem has been caught and that it is being worked on.</p>
</div>
<div class="section" id="specification">
<h1><a class="toc-backref" href="#id7" name="specification">Specification</a></h1>
<p>Checks need to be performed for every ebuild.</p>
<p>A report needs to be generated</p>
<blockquote>
<ul class="simple">
<li>links to the specific problem need to be included</li>
<li>reports need to be send to the groups responsible</li>
</ul>
</blockquote>
<p>Checks could be:</p>
<blockquote>
<ul class="simple">
<li>cycles within DEPEND</li>
<li>invalid SRC_URI</li>
<li>&quot;non-official&quot; USE Flags</li>
<li>Packages within DEPEND that are &quot;*&quot; for the arch specified</li>
<li>broken shell scripts with invalid or missing commands</li>
<li>inheritance of eclasses</li>
<li>...</li>
</ul>
</blockquote>
<p>There might be other checks and tests that should be run
that have not come to my mind yet. Also I might have suggested something that
is not useful at all.</p>
<p>If there are major problems (needs to be defined) within an ebuild a possible
action could be to disable the ebuild (with <tt class="literal"><span class="pre">&quot;-*&quot;</span></tt>,)  perhaps, and send a
mail to the maintainer.</p>
<p>These kind of errors are not always the fault of the developers.</p>
<p>There should be no compilation or something like that. If an ebuild fails to
build somewhere then the user should file it as a bug as usual.</p>
</div>
<div class="section" id="implementation">
<h1><a class="toc-backref" href="#id8" name="implementation">Implementation</a></h1>
<p>The functionality described could be implemented in three ways:</p>
<blockquote>
<ol class="arabic">
<li><dl class="first">
<dt>On the developers machine (&quot;client&quot;) where it is run before checking</dt>
<dd><p class="first last">only for the ebuilds that changed. (client does not fit here because 
the server and client should not communicate with each other at all)</p>
</dd>
</dl>
</li>
<li><p class="first">On the server where checks are run, i.e. once a week.</p>
</li>
<li><p class="first">On the &quot;client&quot; AND server</p>
</li>
</ol>
<p>Of course there are cons and pros (what came to my mind so far)</p>
<ol class="arabic">
<li><blockquote class="first">
<dl>
<dt>pro: </dt>
<dd><ul class="first last simple">
<li>the tree can not become inconsistent in the first place (? see contra)</li>
<li>once an ebuild is checked there is no need to do this again</li>
<li>no dedicated machine necessary</li>
<li>generate traffic only once on one machine</li>
<li>errors that are caught here do not bother later on</li>
</ul>
</dd>
<dt>contra:</dt>
<dd><ul class="first last">
<li><dl class="first">
<dt>the consistency is based on the tool installed </dt>
<dd><p class="first last">(what happens when different devs use different versions ?)</p>
</dd>
</dl>
</li>
<li><dl class="first">
<dt>what happens when the ebuild layout changes and some ebuilds</dt>
<dd><p class="first last">do not get updated ?</p>
</dd>
</dl>
</li>
</ul>
</dd>
</dl>
</blockquote>
</li>
<li><blockquote class="first">
<dl>
<dt>pro:</dt>
<dd><ul class="first last simple">
<li>Properties of other ebuilds might change that fit while writing an ebuild</li>
</ul>
</dd>
<dt>contra:</dt>
<dd><ul class="first last">
<li><p class="first">the errors are found when the ebuild is already in CVS</p>
</li>
<li><p class="first">the whole tree needs to be checked</p>
</li>
<li><dl class="first">
<dt>possibly creates a lot of traffic on every run</dt>
<dd><p class="first last">(-&gt; is there an FTP equivalent to HTTP`s HEAD ?)</p>
</dd>
</dl>
</li>
</ul>
</dd>
</dl>
</blockquote>
</li>
<li><p class="first">see 1. and 2.</p>
</li>
</ol>
</blockquote>
<p>My favorite is 3 . All properties are checked before check-in and 
the properties that change might be checked on a regular basis on the server.
Only solution 3 brings the best from 1 and 2 together while delivering the best result.</p>
<p>I never had a look at portage source but I can imagine that there is a library
that has everything that a developer needs to &quot;query&quot; ebuilds. If not, this
would be a reason for another GLEP (?).</p>
<p>For performance I would use a database (on the server) to store the whole tree before
running the checks. This is not necessary for the &quot;client&quot;.</p>
</div>
<div class="section" id="backwards-compatibility">
<h1><a class="toc-backref" href="#id9" name="backwards-compatibility">Backwards Compatibility</a></h1>
<p>Not a problem for this GLEP.</p>
</div>
<div class="section" id="id1">
<h1><a class="toc-backref" href="#id10" name="id1">References</a></h1>
<table class="footnote" frame="void" id="id2" rules="none">
<colgroup><col class="label" /><col /></colgroup>
<tbody valign="top">
<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>
</tbody>
</table>
</div>
</div>

<hr class="footer" />
<div class="footer">
<a class="reference" href="glep-0035.txt">View document source</a>.
Generated on: 2005-03-12 20:26 UTC.
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.
</div>
</body>
</html>

1	g2boojum	1.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