OK, these are eclasses v3.2:

1. aded kde-objprelink.eclass
2. modified ebuilds accordingly, updated documentation
3. removed old koffice beta ebuilds
4. added new inheriting ebuild for kdelibs (a special case)
5. misc

5 files changed, 204 insertions, 100 deletions

diff --git a/eclass/doc/eclass-howto.lyx b/eclass/doc/eclass-howto.lyx
index f62fe91d766b..5fb233dc8a64 100644
--- a/eclass/doc/eclass-howto.lyx
+++ b/eclass/doc/eclass-howto.lyx
@@ -30,7 +30,7 @@ eclass howto
 Dan Armak
 \layout Date
 
-Updated for eclasses v3
+Updated for eclasses v3.2
 \layout Section
 
 Introduction
@@ -44,18 +44,18 @@ eclasses are parts of ebuilds; that is, they have the same syntax ebuilds
 \layout Standard
 
 The most similar group of ebuilds is the kde apps.
- These have been selected to be the test case for this first incarnation
+ These have been selected to be the test case for the first incarnation
  of eclasses.
- Currently test ebuilds are available for all of kde-2.2.1 (as kde*-2.2.1-r1),
- kdevelop-2.0.1 and koffice-1.1.
- Many others will follow.
+ Inheriting ebuilds are available for all of kde-2.2.1 (as kde*-2.2.1-r1), kdevelop-
+2.0.1 and koffice-1.1.
+ Others will follow.
 \layout Standard
 
-Please read news.txt for an astract of changes between versions of the eclasses.
+Please read news.txt for an abstract of changes between versions of the eclasses.
 \layout Standard
 
-Section two explains how eclasses work.Section three shows a sample inheriting
- ebuild.
+Section two explains how eclasses work; section three explains how to write
+ inheriting ebuilds.
 \layout Subsection
 
 Notes on this document
@@ -68,6 +68,14 @@ ebuild variables/functions
  refers to those used in std.
  ebuilds e.g.
  $S, $P, src_unpack()...
+\layout Itemize
+
+Versioning: I suppose I could have made, instead of versions 1, 2, 3, 3.1,
+ 3.1 versions 0.1, ...
+ 0.3.1, or maybe 0.0.3-1.
+ Usually I would.
+ Not sure why I didn't.
+ Too late to change it now.
 \layout Section
 
 The eclasses
@@ -124,23 +132,14 @@ xbuilds
 ), any name-to-file resolution code will go in here.
 \layout Standard
 
-This function is the entire contents of inherit.eclass.
- In the future, once eclasses are considered to be stable, this function
- will live in ebuild.sh, and every ebuild will be able to use it.
- For now, we don't want to make a new version of portage just for this,
- so we put this function in a separate eclass.
- Every inheriting ebuild begins with these two lines:
+Every inheriting ebuild begins with these two lines:
 \layout Code
 
 .
  /usr/portage/eclass/inherit.eclass || die
 \layout Code
 
-inherit kde-base || die
-\layout Standard
-
-Once the inherit() function goes into ebuild.sh, we can drop the first line;
- there will be no further change necessary.
+inherit <list of eclasses> || die
 \layout Standard
 
 Eclasses do not need this first line, since they are always sourced from
@@ -409,20 +408,14 @@ A final note: not all functions execute all their sections when called with
 all
 \emph default 
  or without parameters.
- Some sections may be non-standrd and must be called explicitly.
- Current examples inculde base_src_unpack
-\emph on 
- patch 
-\emph default 
-and the upcoming kde_src_unpack 
+ Some sections may be non-standard and must be called explicitly.
+ Current examples include base_src_unpack
 \emph on 
-objprelink-patch
-\emph default 
- (whose name may change when I actually write it).
+ patch.
 \layout Standard
 
 A more final note: the eclasses also include some debug statements, which
- are not part of the function/section strufture.
+ are not part of the function/section structure.
  More on this at the debug.eclass section.
 \layout Subsection
 
@@ -483,7 +476,7 @@ Briefly, it handles all standard kde-2.1* and 2.2* apps that need configure/make
 ake install cycles.
  It handles all the std.
  configure options e.g.
- objprelink.
+ qtmt.
  It also adds kdelibs to DEPEND/RDEPEND.
 \layout Standard
 
@@ -492,15 +485,15 @@ Note: some kde apps, like widget styles and i18n packages, do not need to
  Therefore kde.eclass does not inherit c and does not depend on qt.
  These packages can then inherit straight from here (or from kde-i18n.eclass,
  which also inherits from here).
- All other packages, which need to ompile c code and link against qt, should
- inhreit from kde-base.eclass.
+ All other packages, which need to compile c code and link against qt, should
+ inherit from kde-base.eclass.
 \layout Subsection
 
 kde-base.eclass
 \layout Standard
 
 Meant for standard kde apps, of both 2.1 and 2.2 architectures.
- Inherits c,kde and adds objprelink and qt deps.
+ Inherits c,kde and adds qt deps.
  Sets HOMEPAGE=apps.kde.com.
 \layout Subsection
 
@@ -525,7 +518,7 @@ kde-dist.eclass
 \layout Standard
 
 Meant for the base kde distribution packages in kde-base/*.
- Inherits kde-base,kde.org.
+ Inherits kde-base, kde.org and kde-objprelink.
  Adds the correct DESCRIPTION and HOMEPAGE and kdelibs-${PV} deps.
  The simpler/smaller kde-base/ packages (e.g.
  kdetoys) make no changes at all; most of those that do only add deps.
@@ -635,7 +628,7 @@ parameters are $2...
 \begin_inset Quotes erd
 \end_inset 
 
- (all following aprameteres to the function).
+ (all following parameters to the function).
 \layout Standard
 
 debug-print-section() prints 
@@ -666,18 +659,51 @@ Inside debug.eclass are several settings, which can later be moved to some
 \layout Standard
 
 The functions are used in all ebuild functions/sections of all eclasses,
- and in the helper funcions inherit() and EXPORT_FUNCTIONS().
+ and in the helper functions inherit() and EXPORT_FUNCTIONS().
+\layout Standard
+
+Note that all debugging output is off by default.
+ You can change this setting in debug.eclass (for now), but be careful not
+ to commit the new setting to cvs.
+ In addition, debug output is further disabled in inherit() in inherit.eclass
+ to avoid extra-inheriting.
+ You can enable it there by uncommenting the appropriate lines.
 \layout Subsection
 
 kde-objprelink.eclass
 \layout Standard
 
-Will be written soon.
- Will provide the objprelink deps and the 
-\emph on 
-objprelink-patch
-\emph default 
- src_unpack section.
+Provides objprelink deps (>=objprelink-0-r1).
+ Also provides a function kde-objprelink-patch() that applies the kde-admin-acin
+clude patch.
+ Call it and the end of your src_unpack if you need it.
+\layout Standard
+
+Known issue: the actual --enable-objprelink option is passed to configure
+ from kde.eclass, regardless of the inheritance of objprelink.
+ Therefore if:
+\layout Enumerate
+
+A package has builtin objprelink capability which can be activated from
+ configure with --enable-objprelink
+\layout Enumerate
+
+The package does not inherit from kde-objprelink (or kde-dist etc.)
+\layout Enumerate
+
+USE objprelink is set
+\layout Enumerate
+
+>=objprelink-0-r1 is, incidentally, not installed
+\layout Standard
+
+Then, the make process will try to use objprelink, but won't find it and
+ will (may?) fail and abort.
+\layout Standard
+
+However, because the package will depend on kdelibs, which inherits kde-objpreli
+nk through kde-dist, the chances of this happening are practically nil.
+ In any case, I'll try to think of a better solution.
 \layout Section
 
 The inheriting ebuilds
diff --git a/eclass/doc/eclass-howto.sgml b/eclass/doc/eclass-howto.sgml
index 8c7fe87629be..0c287cd11afa 100644
--- a/eclass/doc/eclass-howto.sgml
+++ b/eclass/doc/eclass-howto.sgml
@@ -10,7 +10,7 @@
    Dan Armak
   </author>
   <date>
-   Updated for eclasses v3
+   Updated for eclasses v3.2
   </date>
   <sect1>
    <title>
@@ -20,13 +20,13 @@
    eclasses are parts of ebuilds; that is, they have the same syntax ebuilds do, but do not define all the required variables and functions. ebuilds can inherit from eclasses, and eclasses can inherit from other eclasses. As in OOP, this is used to ensure maximum code reuse among similar ebuilds.
   </para>
   <para>
-   The most similar group of ebuilds is the kde apps. These have been selected to be the test case for this first incarnation of eclasses. Currently test ebuilds are available for all of kde-2.2.1 (as kde*-2.2.1-r1), kdevelop-2.0.1 and koffice-1.1. Many others will follow.
+   The most similar group of ebuilds is the kde apps. These have been selected to be the test case for the first incarnation of eclasses. Inheriting ebuilds are available for all of kde-2.2.1 (as kde*-2.2.1-r1), kdevelop-2.0.1 and koffice-1.1. Others will follow.
   </para>
   <para>
-   Please read news.txt for an astract of changes between versions of the eclasses.
+   Please read news.txt for an abstract of changes between versions of the eclasses.
   </para>
   <para>
-   Section two explains how eclasses work.Section three shows a sample inheriting ebuild.
+   Section two explains how eclasses work; section three explains how to write inheriting ebuilds.
   </para>
    <sect2>
     <title>
@@ -38,6 +38,11 @@
     ebuild variables/functions</emphasis> refers to those used in std. ebuilds e.g. &dollar;S, &dollar;P, src_unpack()...
     </para>
    </listitem>
+    <listitem>
+    <para>
+    Versioning: I suppose I could have made, instead of versions 1, 2, 3, 3.1, 3.1 versions 0.1, ... 0.3.1, or maybe 0.0.3-1. Usually I would. Not sure why I didn't. Too late to change it now.
+    </para>
+   </listitem>
    </itemizedlist>
    </sect2>
   </sect1>
@@ -71,16 +76,13 @@
     This function simply sources files from a hard-coded location. If, in the future, we will decide to move eclasses to a different location or to introduce more &ldquo;formats&rdquo; (like drobbins' projected <emphasis>xbuilds</emphasis>), any name-to-file resolution code will go in here.
    </para>
    <para>
-    This function is the entire contents of inherit.eclass. In the future, once eclasses are considered to be stable, this function will live in ebuild.sh, and every ebuild will be able to use it. For now, we don't want to make a new version of portage just for this, so we put this function in a separate eclass. Every inheriting ebuild begins with these two lines:
+    Every inheriting ebuild begins with these two lines:
    </para>
    <programlisting>
 <![ CDATA [. /usr/portage/eclass/inherit.eclass || die
-]]><![ CDATA [inherit kde-base || die
+]]><![ CDATA [inherit <list of eclasses> || die
 ]]>   </programlisting>
    <para>
-    Once the inherit() function goes into ebuild.sh, we can drop the first line; there will be no further change necessary.
-   </para>
-   <para>
     Eclasses do not need this first line, since they are always sourced from an ebuild which has it.
    </para>
    </sect2>
@@ -202,10 +204,10 @@
      The only way to know what functions contain what sections is to read the eclasses.
     </para>
     <para>
-     A final note: not all functions execute all their sections when called with <emphasis>all</emphasis> or without parameters. Some sections may be non-standrd and must be called explicitly. Current examples inculde base_src_unpack<emphasis> patch </emphasis>and the upcoming kde_src_unpack <emphasis>objprelink-patch</emphasis> (whose name may change when I actually write it).
+     A final note: not all functions execute all their sections when called with <emphasis>all</emphasis> or without parameters. Some sections may be non-standard and must be called explicitly. Current examples include base_src_unpack<emphasis> patch.</emphasis>
     </para>
     <para>
-     A more final note: the eclasses also include some debug statements, which are not part of the function/section strufture. More on this at the debug.eclass section.
+     A more final note: the eclasses also include some debug statements, which are not part of the function/section structure. More on this at the debug.eclass section.
     </para>
     </sect3>
    </sect2>
@@ -244,10 +246,10 @@
     Read it to find out what it defines. It is quite self-explanatory.
    </para>
    <para>
-    Briefly, it handles all standard kde-2.1* and 2.2* apps that need configure/make/make install cycles. It handles all the std. configure options e.g. objprelink. It also adds kdelibs to DEPEND/RDEPEND.
+    Briefly, it handles all standard kde-2.1* and 2.2* apps that need configure/make/make install cycles. It handles all the std. configure options e.g. qtmt. It also adds kdelibs to DEPEND/RDEPEND.
    </para>
    <para>
-    Note: some kde apps, like widget styles and i18n packages, do not need to compile anything. Therefore kde.eclass does not inherit c and does not depend on qt. These packages can then inherit straight from here (or from kde-i18n.eclass, which also inherits from here). All other packages, which need to ompile c code and link against qt, should inhreit from kde-base.eclass.
+    Note: some kde apps, like widget styles and i18n packages, do not need to compile anything. Therefore kde.eclass does not inherit c and does not depend on qt. These packages can then inherit straight from here (or from kde-i18n.eclass, which also inherits from here). All other packages, which need to compile c code and link against qt, should inherit from kde-base.eclass.
    </para>
    </sect2>
    <sect2>
@@ -255,7 +257,7 @@
     kde-base.eclass
    </title>
    <para>
-    Meant for standard kde apps, of both 2.1 and 2.2 architectures. Inherits c,kde and adds objprelink and qt deps. Sets HOMEPAGE=apps.kde.com.
+    Meant for standard kde apps, of both 2.1 and 2.2 architectures. Inherits c,kde and adds qt deps. Sets HOMEPAGE=apps.kde.com.
    </para>
    </sect2>
    <sect2>
@@ -277,7 +279,7 @@
     kde-dist.eclass
    </title>
    <para>
-    Meant for the base kde distribution packages in kde-base/*. Inherits kde-base,kde.org. Adds the correct DESCRIPTION and HOMEPAGE and kdelibs-&dollar;&lcub;PV&rcub; deps. The simpler/smaller kde-base/ packages (e.g. kdetoys) make no changes at all; most of those that do only add deps.
+    Meant for the base kde distribution packages in kde-base/*. Inherits kde-base, kde.org and kde-objprelink. Adds the correct DESCRIPTION and HOMEPAGE and kdelibs-&dollar;&lcub;PV&rcub; deps. The simpler/smaller kde-base/ packages (e.g. kdetoys) make no changes at all; most of those that do only add deps.
    </para>
    </sect2>
    <sect2>
@@ -331,7 +333,7 @@
 ]]><![ CDATA [}
 ]]>   </programlisting>
    <para>
-    debug-print-function() prints &ldquo;now in function &dollar;1&rdquo;, &ldquo;parameters are &dollar;2...&rdquo; (all following aprameteres to the function).
+    debug-print-function() prints &ldquo;now in function &dollar;1&rdquo;, &ldquo;parameters are &dollar;2...&rdquo; (all following parameters to the function).
    </para>
    <para>
     debug-print-section() prints &ldquo;now in section &dollar;1&rdquo;.
@@ -343,7 +345,10 @@
     Inside debug.eclass are several settings, which can later be moved to some external config file. They include turning debug on or off and redirecting its output.
    </para>
    <para>
-    The functions are used in all ebuild functions/sections of all eclasses, and in the helper funcions inherit() and EXPORT_FUNCTIONS().
+    The functions are used in all ebuild functions/sections of all eclasses, and in the helper functions inherit() and EXPORT_FUNCTIONS().
+   </para>
+   <para>
+    Note that all debugging output is off by default. You can change this setting in debug.eclass (for now), but be careful not to commit the new setting to cvs. In addition, debug output is further disabled in inherit() in inherit.eclass to avoid extra-inheriting. You can enable it there by uncommenting the appropriate lines.
    </para>
    </sect2>
    <sect2>
@@ -351,7 +356,38 @@
     kde-objprelink.eclass
    </title>
    <para>
-    Will be written soon. Will provide the objprelink deps and the <emphasis>objprelink-patch</emphasis> src_unpack section.
+    Provides objprelink deps (&gt;=objprelink-0-r1). Also provides a function kde-objprelink-patch() that applies the kde-admin-acinclude patch. Call it and the end of your src_unpack if you need it.
+   </para>
+   <para>
+    Known issue: the actual --enable-objprelink option is passed to configure from kde.eclass, regardless of the inheritance of objprelink. Therefore if:
+   </para>
+   <orderedlist>
+    <listitem>
+    <para>
+    A package has builtin objprelink capability which can be activated from configure with --enable-objprelink
+    </para>
+   </listitem>
+    <listitem>
+    <para>
+    The package does not inherit from kde-objprelink (or kde-dist etc.)
+    </para>
+   </listitem>
+    <listitem>
+    <para>
+    USE objprelink is set
+    </para>
+   </listitem>
+    <listitem>
+    <para>
+    &gt;=objprelink-0-r1 is, incidentally, not installed
+    </para>
+   </listitem>
+   </orderedlist>
+   <para>
+    Then, the make process will try to use objprelink, but won't find it and will (may?) fail and abort.
+   </para>
+   <para>
+    However, because the package will depend on kdelibs, which inherits kde-objprelink through kde-dist, the chances of this happening are practically nil. In any case, I'll try to think of a better solution.
    </para>
    </sect2>
   </sect1>
diff --git a/eclass/doc/eclass-howto.txt b/eclass/doc/eclass-howto.txt
index eaa6fbba4a94..3f7384e9f0d2 100644
--- a/eclass/doc/eclass-howto.txt
+++ b/eclass/doc/eclass-howto.txt
@@ -4,7 +4,7 @@ eclass howto
 
 Dan Armak
 
-Updated for eclasses v3
+Updated for eclasses v3.2
 
 1 Introduction
 
@@ -15,22 +15,27 @@ can inherit from other eclasses. As in OOP, this is used
 to ensure maximum code reuse among similar ebuilds.
 
 The most similar group of ebuilds is the kde apps. These
-have been selected to be the test case for this first incarnation
-of eclasses. Currently test ebuilds are available for all
-of kde-2.2.1 (as kde*-2.2.1-r1), kdevelop-2.0.1 and koffice-1.1.
-Many others will follow.
+have been selected to be the test case for the first incarnation
+of eclasses. Inheriting ebuilds are available for all of
+kde-2.2.1 (as kde*-2.2.1-r1), kdevelop-2.0.1 and koffice-1.1.
+Others will follow.
 
-Please read news.txt for an astract of changes between versions
+Please read news.txt for an abstract of changes between versions
 of the eclasses.
 
-Section two explains how eclasses work.Section three shows
-a sample inheriting ebuild.
+Section two explains how eclasses work; section three explains
+how to write inheriting ebuilds.
 
 1.1 Notes on this document
 
 * ebuild variables/functions refers to those used in std.
   ebuilds e.g. $S, $P, src_unpack()...
 
+* Versioning: I suppose I could have made, instead of versions
+  1, 2, 3, 3.1, 3.1 versions 0.1, ... 0.3.1, or maybe 0.0.3-1.
+  Usually I would. Not sure why I didn't. Too late to change
+  it now.
+
 2 The eclasses
 
 The best way of becoming familiar with the current eclass
@@ -62,19 +67,11 @@ different location or to introduce more "formats"
 (like drobbins' projected xbuilds), any name-to-file resolution
 code will go in here.
 
-This function is the entire contents of inherit.eclass. In
-the future, once eclasses are considered to be stable, this
-function will live in ebuild.sh, and every ebuild will be
-able to use it. For now, we don't want to make a new version
-of portage just for this, so we put this function in a separate
-eclass. Every inheriting ebuild begins with these two lines:
+Every inheriting ebuild begins with these two lines:
 
 . /usr/portage/eclass/inherit.eclass || die
 
-inherit kde-base || die
-
-Once the inherit() function goes into ebuild.sh, we can drop
-the first line; there will be no further change necessary.
+inherit <list of eclasses> || die
 
 Eclasses do not need this first line, since they are always
 sourced from an ebuild which has it.
@@ -244,13 +241,11 @@ is to read the eclasses.
 
 A final note: not all functions execute all their sections
 when called with all or without parameters. Some sections
-may be non-standrd and must be called explicitly. Current
-examples inculde base_src_unpack patch and the upcoming
-kde_src_unpack objprelink-patch (whose name may change when
-I actually write it).
+may be non-standard and must be called explicitly. Current
+examples include base_src_unpack patch.
 
 A more final note: the eclasses also include some debug statements,
-which are not part of the function/section strufture. More
+which are not part of the function/section structure. More
 on this at the debug.eclass section.
 
 2.3 base.eclass
@@ -290,21 +285,21 @@ Read it to find out what it defines. It is quite self-explanatory.
 
 Briefly, it handles all standard kde-2.1* and 2.2* apps that
 need configure/make/make install cycles. It handles all
-the std. configure options e.g. objprelink. It also adds
-kdelibs to DEPEND/RDEPEND.
+the std. configure options e.g. qtmt. It also adds kdelibs
+to DEPEND/RDEPEND.
 
 Note: some kde apps, like widget styles and i18n packages,
 do not need to compile anything. Therefore kde.eclass does
 not inherit c and does not depend on qt. These packages
 can then inherit straight from here (or from kde-i18n.eclass,
 which also inherits from here). All other packages, which
-need to ompile c code and link against qt, should inhreit
+need to compile c code and link against qt, should inherit
 from kde-base.eclass.
 
 2.5 kde-base.eclass
 
 Meant for standard kde apps, of both 2.1 and 2.2 architectures.
-Inherits c,kde and adds objprelink and qt deps. Sets HOMEPAGE=apps.kde.com.
+Inherits c,kde and adds qt deps. Sets HOMEPAGE=apps.kde.com.
 
 2.6 kde-i18n.eclass
 
@@ -320,10 +315,10 @@ as PROVIDE virtual/kde-i18n, correct $S, HOMEPAGE and DESCRIPTION.
 2.7 kde-dist.eclass
 
 Meant for the base kde distribution packages in kde-base/*.
-Inherits kde-base,kde.org. Adds the correct DESCRIPTION
-and HOMEPAGE and kdelibs-${PV} deps. The simpler/smaller
-kde-base/ packages (e.g. kdetoys) make no changes at all;
-most of those that do only add deps.
+Inherits kde-base, kde.org and kde-objprelink. Adds the
+correct DESCRIPTION and HOMEPAGE and kdelibs-${PV} deps.
+The simpler/smaller kde-base/ packages (e.g. kdetoys) make
+no changes at all; most of those that do only add deps.
 
 2.8 c.eclass
 
@@ -386,7 +381,7 @@ base_src_install() {
 
 debug-print-function() prints "now
 in function $1", "parameters
-are $2..." (all following aprameteres to the function).
+are $2..." (all following parameters to the function).
 
 debug-print-section() prints "now
 in section $1".
@@ -398,12 +393,44 @@ be moved to some external config file. They include turning
 debug on or off and redirecting its output.
 
 The functions are used in all ebuild functions/sections of
-all eclasses, and in the helper funcions inherit() and EXPORT_FUNCTIONS().
+all eclasses, and in the helper functions inherit() and
+EXPORT_FUNCTIONS().
+
+Note that all debugging output is off by default. You can
+change this setting in debug.eclass (for now), but be careful
+not to commit the new setting to cvs. In addition, debug
+output is further disabled in inherit() in inherit.eclass
+to avoid extra-inheriting. You can enable it there by uncommenting
+the appropriate lines.
 
 2.11 kde-objprelink.eclass
 
-Will be written soon. Will provide the objprelink deps and
-the objprelink-patch src_unpack section.
+Provides objprelink deps (>=objprelink-0-r1). Also provides
+a function kde-objprelink-patch() that applies the kde-admin-acinclude
+patch. Call it and the end of your src_unpack if you need
+it.
+
+Known issue: the actual --enable-objprelink option is passed
+to configure from kde.eclass, regardless of the inheritance
+of objprelink. Therefore if:
+
+1. A package has builtin objprelink capability which can be
+  activated from configure with --enable-objprelink
+
+2. The package does not inherit from kde-objprelink (or kde-dist
+  etc.)
+
+3. USE objprelink is set
+
+4. >=objprelink-0-r1 is, incidentally, not installed
+
+Then, the make process will try to use objprelink, but won't
+find it and will (may?) fail and abort.
+
+However, because the package will depend on kdelibs, which
+inherits kde-objprelink through kde-dist, the chances of
+this happening are practically nil. In any case, I'll try
+to think of a better solution.
 
 3 The inheriting ebuilds
 
diff --git a/eclass/doc/news.txt b/eclass/doc/news.txt
index 42d591be1ed3..bd06c53c9b4d 100644
--- a/eclass/doc/news.txt
+++ b/eclass/doc/news.txt
@@ -1,3 +1,12 @@
+3/10
+v3.2
+Addition of kde-objprelink, further minor changes and fixes.
+You now inherit from kde-objprelink. If you need the admin patch, run kde-objprelink-patch()
+at the end of src_unpack. kde-dist inherits from kde-objprelink, other eclasses do not.
+
+2/10
+Unmasking of eclasses. Other developers test, but do not use in their work. Evaluation period.
+
 1/10
 v3.1
 Addition of debug.eclass.
@@ -41,4 +50,4 @@ Documented in original howto
 29/9
 v1
 Original version
-Had an infinite recursion in base.eclass. Was deleted from cvs later that day.
\ No newline at end of file
+Had an infinite recursion in base.eclass. Was deleted from cvs later that day.
diff --git a/eclass/doc/todo.txt b/eclass/doc/todo.txt
index 694ffeef544f..845d935e7269 100644
--- a/eclass/doc/todo.txt
+++ b/eclass/doc/todo.txt
@@ -1,14 +1,20 @@
-debug.eclass - debug levels
+inverse section requests (I like fancy names)
 
-kde-objprelink.eclass
+newdepend() in virtual.eclass, consider functions.eclass or similar
+
+debug.eclass - tee output to file
+
+kde-objprelink.eclass - cancelled, integrate into kde.eclass
 
 decide where qt deps versioning should go
 
 koffice-i18n packages
 
--r1 packages for all kde apps in portage
+-r1 packages for all kde apps in portage - update versions and build all
 
 sort out docs/sgml, get link from site
 
-make scheme stable and unmask
+cleanup or remove kde.org.eclass
+
+new inheriting kdelibs ebuild