--- xml/htdocs/proj/en/glep/glep-0035.html 2005/03/12 20:26:19 1.1 +++ xml/htdocs/proj/en/glep/glep-0035.html 2006/10/10 20:25:14 1.2 @@ -8,9 +8,252 @@ --> - + GLEP 35 -- Automated consistency check for ebuilds - + -
- +
@@ -35,7 +277,7 @@ - + @@ -43,7 +285,7 @@ - + @@ -52,8 +294,8 @@
Version:1.1
Last-Modified:2005/03/12 20:26:01
Last-Modified:2005/03/12 20:26:01
Author:Adrian Lambeck <adrian at basicsedv.de>,
Type:Standards Track
Content-Type:text/x-rst
Content-Type:text/x-rst
Created:12-Mar-2005

-
-

Contents

+
+

Contents

-
-

Abstract

+
+

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 @@ -72,8 +314,8 @@ Why bother with trivial bugs when automated tests find them ? Save time and improve quality !

-
-

Motivation

+
+

Motivation

When browsing bugs.gentoo.org [1] 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 @@ -86,8 +328,8 @@

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

+
+

Specification

Checks need to be performed for every ebuild.

A report needs to be generated

@@ -112,20 +354,20 @@ 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 +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

+
+

Implementation

The functionality described could be implemented in three ways:

    -
  1. +
  2. On the developers machine ("client") where it is run before checking
    -

    only for the ebuilds that changed. (client does not fit here because +

    only for the ebuilds that changed. (client does not fit here because the server and client should not communicate with each other at all)

    @@ -137,9 +379,8 @@

Of course there are cons and pros (what came to my mind so far)

    -
  1. -
    -
    pro:
    +
  2. +
    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
    • @@ -150,13 +391,13 @@
    contra:
      -
    • -
      the consistency is based on the tool installed
      +
    • +
      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 ?

      @@ -165,10 +406,8 @@
    -
  3. -
  4. -
    +
  5. pro:
    • Properties of other ebuilds might change that fit while writing an ebuild
    • @@ -180,7 +419,7 @@
    • 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 ?)

      @@ -189,13 +428,12 @@
    -
  6. see 1. and 2.

-

My favorite is 3 . All properties are checked before check-in and +

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 @@ -204,26 +442,27 @@

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".

- - +