diff options
Diffstat (limited to 'glep-0035.rst')
| -rw-r--r-- | glep-0035.rst | 134 |
1 files changed, 134 insertions, 0 deletions
diff --git a/glep-0035.rst b/glep-0035.rst new file mode 100644 index 0000000..1644ab9 --- /dev/null +++ b/glep-0035.rst @@ -0,0 +1,134 @@ +GLEP: 35 +Title: Automated consistency check for ebuilds +Version: $Revision$ +Last-Modified: $Date$ +Author: Adrian Lambeck <adrian@basicsedv.de>, +Status: Deferred +Type: Standards Track +Content-Type: text/x-rst +Created: 12-Mar-2005 +Post-History: 12-Mar-2005 + + +Abstract +======== + +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 ! + + +Motivation +========== + +When browsing `bugs.gentoo.org`_ 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 +duplicates. 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 `bugs.gentoo.org`_. So there will +(hopefully) be fewer bugs that need to be checked and assigned and they might +get fixed faster. + +.. _bugs.gentoo.org: http://bugs.gentoo.org + +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. + + +Specification +============= + +Checks need to be performed for every ebuild. + +A report needs to be generated + + - links to the specific problem need to be included + - reports need to be send to the groups responsible + +Checks could be: + + - cycles within DEPEND + - invalid SRC_URI + - "non-official" USE Flags + - Packages within DEPEND that are "*" for the arch specified + - broken shell scripts with invalid or missing commands + - inheritance of eclasses + - ... + +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. + +If there are major problems (needs to be defined) within an ebuild a possible +action could be to disable the ebuild (with ``"-*"``,) perhaps, and send a +mail to the maintainer. + +These kind of errors are not always the fault of the developers. + +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. + + +Implementation +============== + +The functionality described could be implemented in three ways: + + 1. On the developers machine ("client") where it is run before checking + only for the ebuilds that changed. (client does not fit here because + the server and client should not communicate with each other at all) + + 2. On the server where checks are run, i.e. once a week. + + 3. On the "client" AND server + + + Of course there are cons and pros (what came to my mind so far) + + 1. + pro: + - the tree can not become inconsistent in the first place (? see contra) + - once an ebuild is checked there is no need to do this again + - no dedicated machine necessary + - generate traffic only once on one machine + - errors that are caught here do not bother later on + + contra: + - the consistency is based on the tool installed + (what happens when different devs use different versions ?) + - what happens when the ebuild layout changes and some ebuilds + do not get updated ? + + 2. + pro: + - Properties of other ebuilds might change that fit while writing an ebuild + + contra: + - the errors are found when the ebuild is already in CVS + - the whole tree needs to be checked + - possibly creates a lot of traffic on every run + (-> is there an FTP equivalent to HTTP`s HEAD ?) + + 3. see 1. and 2. + +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. + +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 "query" ebuilds. If not, this +would be a reason for another GLEP (?). + +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 "client". + + +Backwards Compatibility +======================= + +Not a problem for this GLEP. |