| 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 |
|
Parent Directory
| 
Revision Log
