Re: [gentoo-dev] [PMS] Add RESTRICT=distcc capability

2008-11-02 Thread Ciaran McCreesh
On Sat, 1 Nov 2008 18:29:03 -0700
Gordon Malm [EMAIL PROTECTED] wrote:
 You're the one assuming the only purpose would be to mask parallel
 make problems.  Apparently it does have a purpose though since
 avidemux builds fine in parallel but NOT via distcc.

Have you conclusively established that they do build fine in parallel?
If so, how? And why do they break in parallel only under distcc? Given
how distcc works, this strikes me as somewhat implausible...

 Back to your most recent post
   *If* there's a legitimate use for RESTRICT=distcc then I am
  entirely in favour of it. But it looks like there isn't, with every
  issue being either a parallelism issue (which RESTRICT=distcc won't
  fix), a user configuration issue (which RESTRICT=distcc won't fix)
  or a hardened toolchain bug (for which RESTRICT=distcc is massive
  overkill, and thus the wrong solution). You've decided upon a
  solution before you've worked out what the problem is.
 
 You assumed it is a parallelism issue that people are trying to
 solve.  I haven't pointed to any user configuration issues.  Using
 RESTRICT=distcc on kernel modules is hardly overkill.  This isn't
 openoffice.  I know exactly what the problem is, but since you have
 such a better grasp on it

RESTRICT=distcc on kernel modules is unnecessary for the large
proportion of users who don't use hardened. RESTRICTs can't be set
dependent upon whether or not something like hardenened is enabled;
other mechanisms are available that can be. So why aren't you
considering those other mechanisms?

 We have to build using different specs sets for kernel code than
 userland.  If we can't depend on the __KERNEL__ macro for detection,
 how else do you propose one detect if gcc is building kernel code or
 not?

A macro is just a macro. All it does is affect the preprocessor stage.
Hardened is trying to abuse it for something else entirely, which is why
you're encountering problems.

 What makes it any better than a simple option to RESTRICT distcc?

You still appear to be confusing RESTRICT distcc and provide a
mechanism for selectively disabling distcc. They are entirely
different things.

 I guess the larger question in all this is why does a third party who
 has demonstrated his anti-Hardened (and anti-Gentoo) slant on
 multiple occasions define what goes in our PMS?

Uh, that's your answer to technical objections to a proposal? You
aren't prepared to defend your proposal on its merits?

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


Re: [gentoo-dev] [PMS] Add RESTRICT=distcc capability

2008-11-02 Thread Ciaran McCreesh
On Sun, 2 Nov 2008 12:11:10 -0700
Gordon Malm [EMAIL PROTECTED] wrote:
  Have you conclusively established that they do build fine in
  parallel? If so, how? And why do they break in parallel only under
  distcc? Given how distcc works, this strikes me as somewhat
  implausible...
 
 Yes it builds in parallel.  By compiling it in parallel.  I don't
 know why and don't care to investigate for you.  It's not my package,
 I'm not QA and my team is short staffed enough as it is.  We have to
 take care of our own backyard.  Maybe you could investigate the
 answers to your own questions? How about you at least feign attempt
 at answering my questions for a change?

If you think compiling it in parallel confirms that it builds in
parallel, you're reaffirming my growing suspicion that you're entirely
wrong about distcc being responsible for anything other than hardened
brokenness...

  RESTRICT=distcc on kernel modules is unnecessary for the large
  proportion of users who don't use hardened. RESTRICTs can't be set
  dependent upon whether or not something like hardenened is enabled;
  other mechanisms are available that can be. So why aren't you
  considering those other mechanisms?
 
 I agree with the first sentence, never said otherwise.  Who says I am
 not considering them?  In fact, I have stated that I am.  They are
 just more hackish than adding the ability to RESTRICT distcc, hence
 my reason for soliciting such a feature.  I'm surprised that you'd
 suggest this after debasing a RESTRICT option on the same grounds.

And that brings us to the other thing you don't understand: RESTRICT is
a global, system independent, invariant metadata key. Things in
RESTRICT are in RESTRICT because they have to be known in situations
where those constraints are in effect. Things that do not have to be
known at the metadata level shouldn't be in metadata.

  A macro is just a macro. All it does is affect the preprocessor
  stage. Hardened is trying to abuse it for something else entirely,
  which is why you're encountering problems.
 
 You can cry abuse all you want.  You FAIL to offer any alternatives
 or solutions.  I'll ask again, how do you detect that you are
 compiling code destined to be run in-kernel from within gcc without
 checking for the __KERNEL__ macro?  I think we both know the answer.

I suggest you talk to hardened upstream and see what they have to say
about it. What have they offered as justification for using -D in a way
in which no-one else uses it? What are their objections to switching to
an approach that doesn't break the preprocessor model?

 Sorry to everyone who e-mailed me who thought RESTRICT=distcc would
 be somewhat useful.

Those people are mistaken.

  Uh, that's your answer to technical objections to a proposal? You
  aren't prepared to defend your proposal on its merits?
 
 Why are you assuming this point is *at all* related to my proposal?
 It's not. It's about Gentoo.  But I stand corrected, a bunch of
 people rushed to tell me you don't actually determine anything. ;)

So you don't care about whether your solution is right?

You are proposing to add a metadata invariant option for a condition
that isn't metadata invariant and that, by being made metadata
invariant, means it's being disabled for everyone rather than by the
small number of users who might need it. In addition, you can't
demonstrate any cases where this option is genuinely useful, other than
as a workaround for a hardened bug that you haven't contacted upstream
about, and when used to work around said hardened bug the scope of the
change isn't limited to hardened.

You still haven't explained why you don't do something like:

broken_hardened_compiler  export DISTCC_HOSTS=localhost

-- 
Ciaran McCreesh


signature.asc
Description: PGP signature


[gentoo-dev] Malformed XML - Re: [gentoo-commits] gentoo-x86 commit in app-pda/barry: ChangeLog metadata.xml

2008-11-02 Thread Robin H. Johnson
On Sun, Nov 02, 2008 at 05:08:28PM +, Jorge Manuel B. S. Vicetto 
(jmbsvicetto) wrote:
 jmbsvicetto08/11/02 17:08:28
 
   Modified: ChangeLog metadata.xml
   Log:
   Removing jsin as a maintainer since he was retired.
   (Portage version: 2.2_rc12/cvs/Linux 2.6.27-gentoo x86_64)
...
 ===
 RCS file: /var/cvsroot/gentoo-x86/app-pda/barry/metadata.xml,v
 retrieving revision 1.1
 retrieving revision 1.2
 diff -u -r1.1 -r1.2
 --- metadata.xml  15 Sep 2007 19:00:02 -  1.1
 +++ metadata.xml  2 Nov 2008 17:08:28 -   1.2
 @@ -1,14 +1,11 @@
  ?xml version=1.0 encoding=UTF-8?
  !DOCTYPE pkgmetadata SYSTEM http://www.gentoo.org/dtd/metadata.dtd;
  pkgmetadata
 - herdapp-pda/herd
 - maintainer
 - email[EMAIL PROTECTED]/email
 - nameJason Smathers (jsin)/name
 - /maintainer
 - longdescription lang=en
 - Barry is an Open Source Linux application that will 
 - allow synchronization, backup, restore, program 
 - management, and charging for BlackBerry devices.
 - /longdescription
 +herdapp-pda/herd
 +maintainer
 +longdescription lang=en
 +  Barry is an Open Source Linux application that will
 +  allow synchronization, backup, restore, program 
 +  management, and charging for BlackBerry devices.
 +/longdescription
  /pkgmetadata

Unclosed maintainer tag. How did you commit this? Repoman is supposed
to catch it. If repoman only warns, can we upgrade to critical for
malformed XML?

-- 
Robin Hugh Johnson
Gentoo Linux Developer  Infra Guy
E-Mail : [EMAIL PROTECTED]
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85


pgpx4rSgMbriY.pgp
Description: PGP signature


Re: [gentoo-dev] Malformed XML - Re: [gentoo-commits] gentoo-x86 commit in app-pda/barry: ChangeLog metadata.xml

2008-11-02 Thread Zac Medico
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Robin H. Johnson wrote:
 Unclosed maintainer tag. How did you commit this? Repoman is supposed
 to catch it. If repoman only warns, can we upgrade to critical for
 malformed XML?

Indeed, repoman treats it as a warning. I'll go ahead and make it fatal.
- --
Thanks,
Zac
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEARECAAYFAkkOHnEACgkQ/ejvha5XGaM87gCgh9/elieal09hgtgw3oXDSdYf
OvoAn0Fn2ZZFGbwXf1A3+yGshi6FwRAj
=K/lX
-END PGP SIGNATURE-



[gentoo-dev] Proposed change to base.eclass: EAPI-2 support

2008-11-02 Thread Peter Alfredsen
The attached patch for bug 238753 makes base.eclass support EAPI 2 
functions. None of the previous functionality of exported functions is 
changed, so you can still do base_src_unpack autopatch. It's only the 
default actions of base_src_compile and base_src_unpack that's affected 
and only if EAPI=2. The case..esac for EXPORT_FUNCTIONS is borrowed 
from kde4-base. I've not done tree-rebuilds with this, so please give 
it a thorough review. I'm not entirely happy about the base_src_work 
and base_src_util function names, so suggestions are welcome.


-- 
/PA
--- /usr/portage/eclass/base.eclass	2008-07-17 12:06:27.0 +0200
+++ base.eclass	2008-11-02 22:52:10.0 +0100
@@ -2,32 +2,78 @@
 # Distributed under the terms of the GNU General Public License v2
 # $Header: /var/cvsroot/gentoo-x86/eclass/base.eclass,v 1.34 2008/07/17 09:49:14 pva Exp $
 
 # @ECLASS: base.eclass
 # @MAINTAINER:
-# ???
+# Peter Alfredsen [EMAIL PROTECTED]
 #
 # Original author Dan Armak [EMAIL PROTECTED]
 # @BLURB: The base eclass defines some default functions and variables.
 # @DESCRIPTION:
 # The base eclass defines some default functions and variables. Nearly
 # everything else inherits from here.
+#
+# NOTE: You must define EAPI before inheriting from base, or the wrong functions
+# may be exported.
 
 
 inherit eutils
 
+case ${EAPI} in
+	2)
+		EXPORT_FUNCTIONS src_unpack src_prepare src_configure src_compile src_install
+		;;
+	*)
+		EXPORT_FUNCTIONS src_unpack src_compile src_install
+		;;
+esac
+
 DESCRIPTION=Based on the $ECLASS eclass
 
 # @FUNCTION: base_src_unpack
 # @USAGE: [ unpack ] [ patch ] [ autopatch ] [ all ]
 # @DESCRIPTION:
 # The base src_unpack function, which is exported. If no argument is given,
-# all is assumed.
+# all is assumed if EAPI!=2, unpack if EAPI=2.
 base_src_unpack() {
 
 	debug-print-function $FUNCNAME $*
-	[ -z $1 ]  base_src_unpack all
+
+	if [ -z $1 ]
+	then
+		case ${EAPI} in
+			2)
+base_src_util unpack
+;;
+			*)
+base_src_util all
+;;
+		esac
+	else
+		base_src_util $1
+	fi
+}
+
+# @FUNCTION: base_src_prepare
+# @DESCRIPTION:
+# The base src_prepare function, which is exported when EAPI=2. Performs
+# base_src_util autopatch.
+base_src_prepare() {
+
+	debug-print-function $FUNCNAME $*
+
+	base_src_util autopatch
+}
+
+# @FUNCTION: base_src_util
+# @USAGE: [ unpack ] [ patch ] [ autopatch ] [ all ]
+# @DESCRIPTION:
+# The base_src_util function is the grunt function for base src_unpack
+# and base src_prepare.
+base_src_util() {
+
+	debug-print-function $FUNCNAME $*
 
 	cd ${WORKDIR}
 
 	while [ $1 ]; do
 
@@ -57,28 +103,62 @@
 done
 			fi
 			;;
 		all)
 			debug-print-section all
-			base_src_unpack unpack autopatch
+			base_src_util unpack autopatch
 			;;
 		esac
 
 	shift
 	done
 
 }
 
+# @FUNCTION: base_src_configure
+# @DESCRIPTION:
+# The base src_prepare function, which is exported when EAPI=2. Performs
+# base_src_work configure.
+base_src_configure() {
+
+	debug-print-function $FUNCNAME $*
+
+	base_src_work configure
+}
+
 # @FUNCTION: base_src_compile
 # @USAGE: [ configure ] [ make ] [ all ]
 # @DESCRIPTION:
 # The base src_compile function, which is exported. If no argument is given,
-# all is asasumed.
+# all is assumed if EAPI!=2, compile if EAPI=2.
 base_src_compile() {
 
 	debug-print-function $FUNCNAME $*
-	[ -z $1 ]  base_src_compile all
+
+	if [ -z $1 ]
+	then
+		case ${EAPI} in
+			2)
+base_src_work make
+;;
+			*)
+base_src_work all
+;;
+		esac
+	else
+		base_src_work $1
+	fi
+}
+
+# @FUNCTION: base_src_work
+# @USAGE: [ configure ] [ make ] [ all ]
+# @DESCRIPTION:
+# The base_src_work function is the grunt function for base src_configure
+# and base src_compile.
+base_src_work() {
+
+	debug-print-function $FUNCNAME $*
 
 	cd ${S}
 
 	while [ $1 ]; do
 
@@ -91,11 +171,11 @@
 			debug-print-section make
 			emake || die died running emake, $FUNCNAME:make
 			;;
 		all)
 			debug-print-section all
-			base_src_compile configure make
+			base_src_work configure make
 			;;
 	esac
 
 	shift
 	done


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] Proposed change to base.eclass: EAPI-2 support

2008-11-02 Thread Peter Alfredsen
On Sunday 02 November 2008, Peter Alfredsen wrote:
[...]

Please just imagine that this is added to the end of the patch:
-
-EXPORT_FUNCTIONS src_unpack src_compile src_install

/me had started hacking on this in-tree, and the first change was 
removing that line.

-- 
/PA


signature.asc
Description: This is a digitally signed message part.


[gentoo-dev] Automated Package Removal and Addition Tracker, for the week ending 2008-11-02 23h59 UTC

2008-11-02 Thread Robin H. Johnson
The attached list notes all of the packages that were added or removed
from the tree, for the week ending 2008-11-02 23h59 UTC.

Removals:
x11-drivers/xf86-video-i810 2008-10-27 09:55:08 remi
kde-base/phonon 2008-11-02 07:48:32 vapier
kde-base/plasma 2008-11-02 19:16:30 jmbsvicetto
kde-base/strigi-analyzer2008-11-02 19:17:20 jmbsvicetto

Additions:
x11-apps/fusion-icon2008-10-27 00:48:37 jmbsvicetto
sys-devel/crossdev-wrappers 2008-10-27 04:20:48 solar
games-arcade/tuxanci2008-10-27 07:37:04 scarabeus
dev-perl/HTTP-Response-Encoding 2008-10-27 11:26:46 tove
dev-lang/cilk   2008-10-27 14:41:53 bicatali
sci-libs/taucs  2008-10-27 14:59:18 bicatali
sci-mathematics/cgal2008-10-27 15:17:24 bicatali
dev-python/cgal-python  2008-10-27 15:31:27 bicatali
dev-python/natgrid  2008-10-27 15:54:28 bicatali
x11-apps/simple-ccsm2008-10-27 22:39:41 jmbsvicetto
net-misc/miniupnpd  2008-10-27 22:42:43 gurligebis
app-portage/porticron   2008-10-28 12:17:34 hollow
net-misc/throttle   2008-10-29 13:34:02 grobian
app-benchmarks/gtkperf  2008-10-29 14:23:50 leio
dev-util/lsuio  2008-10-29 18:10:25 vapier
sci-biology/iqpnni  2008-10-30 13:43:35 weaver
virtual/perl-Archive-Tar2008-11-01 18:45:57 yuval
virtual/perl-Class-ISA  2008-11-01 18:45:57 yuval
virtual/perl-Compress-Raw-Zlib  2008-11-01 18:45:57 yuval
virtual/perl-Compress-Zlib  2008-11-01 18:45:58 yuval
virtual/perl-Digest-SHA 2008-11-01 18:45:58 yuval
virtual/perl-ExtUtils-CBuilder  2008-11-01 18:45:58 yuval
virtual/perl-ExtUtils-ParseXS   2008-11-01 18:45:58 yuval
virtual/perl-IO-Compress-Base   2008-11-01 18:45:59 yuval
virtual/perl-IO-Compress-Zlib   2008-11-01 18:45:59 yuval
virtual/perl-IO-Zlib2008-11-01 18:45:59 yuval
virtual/perl-Locale-Maketext-Simple 2008-11-01 18:45:59 yuval
virtual/perl-Math-BigInt-FastCalc   2008-11-01 18:45:59 yuval
virtual/perl-Module-Build   2008-11-01 18:46:00 yuval
virtual/perl-Module-Pluggable   2008-11-01 18:46:00 yuval
virtual/perl-Pod-Escapes2008-11-01 18:46:00 yuval
virtual/perl-Pod-Simple 2008-11-01 18:46:00 yuval
virtual/perl-Term-ANSIColor 2008-11-01 18:46:00 yuval
virtual/perl-Time-Piece 2008-11-01 18:46:00 yuval
virtual/perl-version2008-11-01 18:46:01 yuval
x11-drivers/xf86-input-tslib2008-11-01 21:30:53 solar
media-libs/iulib2008-11-02 06:58:28 vapier
perl-core/Archive-Tar   2008-11-02 07:15:54 tove
perl-core/Class-ISA 2008-11-02 07:16:47 tove
perl-core/Compress-Raw-Zlib 2008-11-02 07:17:55 tove
perl-core/Compress-Zlib 2008-11-02 07:19:04 tove
perl-core/Digest-SHA2008-11-02 07:19:53 tove
perl-core/ExtUtils-CBuilder 2008-11-02 07:20:59 tove
perl-core/ExtUtils-ParseXS  2008-11-02 07:22:04 tove
perl-core/IO-Compress-Base  2008-11-02 07:23:08 tove
perl-core/IO-Compress-Zlib  2008-11-02 07:24:10 tove
perl-core/IO-Zlib   2008-11-02 07:25:12 tove
perl-core/Locale-Maketext-Simple2008-11-02 07:25:54 tove
perl-core/Math-BigInt-FastCalc  2008-11-02 07:26:34 tove
perl-core/Module-Build  2008-11-02 07:27:45 tove
perl-core/Module-Pluggable  2008-11-02 07:28:37 tove
perl-core/Pod-Escapes   2008-11-02 07:29:36 tove
perl-core/Pod-Simple2008-11-02 07:30:37 tove
perl-core/Term-ANSIColor2008-11-02 07:31:24 tove
perl-core/Time-Piece2008-11-02 07:32:11 tove
perl-core/version   2008-11-02 07:33:21 tove
sci-mathematics/qtoctave2008-11-02 16:03:51 markusle

--
Robin Hugh Johnson
Gentoo Linux Developer
E-Mail : [EMAIL PROTECTED]
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85
Removed Packages:
x11-drivers/xf86-video-i810,removed,remi,2008-10-27 09:55:08
kde-base/phonon,removed,vapier,2008-11-02 07:48:32
kde-base/plasma,removed,jmbsvicetto,2008-11-02 19:16:30
kde-base/strigi-analyzer,removed,jmbsvicetto,2008-11-02 19:17:20
Added Packages:
x11-apps/fusion-icon,added,jmbsvicetto,2008-10-27 00:48:37
sys-devel/crossdev-wrappers,added,solar,2008-10-27 04:20:48

Re: [gentoo-dev] Flags to punt (including: kerberos USE flag)

2008-11-02 Thread Nirbheek Chauhan
On Sat, Nov 1, 2008 at 1:39 PM, David Leverton [EMAIL PROTECTED] wrote:
 On Saturday 01 November 2008 02:44:50 Josh Saddler wrote:
 emboss - Seriously. Who needs the European Biology Open Software Suite
 on a *desktop* oriented system?

 That flag is only used by a few sci-biology packages, so if you don't have any
 of those installed, it doesn't matter whether the flag is on or off.  IIRC
 the argument for having it on was that the majority of people who /do/ use
 those packages will want it.

 I suppose one could say that it should be set in IUSE or profile package.use
 instead, but IMHO, if there are enough packages using it to justify making it
 a global flag in the first place, and all of them need the same default, it
 makes sense to set the default globally (*cough*ocamlopt*cough*).

Why not use EAPI=1 for those ebuilds and turn the flag on by default?
Same for the panel stuff for which +eds is good for integration? I
think EAPI=1 +use should be used to de-pollute the desktop etc
profiles :)

IIRC, there are enough stable versions of portage with EAPI=1 support.


-- 
~Nirbheek Chauhan



Re: [gentoo-dev] Proposed change to base.eclass: EAPI-2 support

2008-11-02 Thread Donnie Berkholz
On 00:08 Mon 03 Nov , Peter Alfredsen wrote:
 +case ${EAPI} in
 + 2)
 + EXPORT_FUNCTIONS src_unpack src_prepare src_configure 
 src_compile src_install
 + ;;
 + *)
 + EXPORT_FUNCTIONS src_unpack src_compile src_install
 + ;;
 +esac
 +

This eclass needs to do the same thing as the other eclasses that got 
EAPI=2 patches and default EAPI to 0 when it's not defined, everywhere 
where it tests the value of EAPI.

-- 
Thanks,
Donnie

Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com


pgpNlXoc32bCu.pgp
Description: PGP signature


Re: [gentoo-dev] Proposed change to base.eclass: EAPI-2 support

2008-11-02 Thread Donnie Berkholz
On 20:49 Sun 02 Nov , Donnie Berkholz wrote:
 On 00:08 Mon 03 Nov , Peter Alfredsen wrote:
  +case ${EAPI} in
  +   2)
  +   EXPORT_FUNCTIONS src_unpack src_prepare src_configure 
  src_compile src_install
  +   ;;
  +   *)
  +   EXPORT_FUNCTIONS src_unpack src_compile src_install
  +   ;;
  +esac
  +
 
 This eclass needs to do the same thing as the other eclasses that got 
 EAPI=2 patches and default EAPI to 0 when it's not defined, everywhere 
 where it tests the value of EAPI.

Yeah, I realize it might technically work, but it's just asking for 
breakage in my opinion. Better to be explicit and have the '*' case be 
for something unexpected instead of an expected case.

-- 
Thanks,
Donnie

Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com


pgpOp3iAdqqL7.pgp
Description: PGP signature


Re: [gentoo-dev] Proposed change to base.eclass: EAPI-2 support

2008-11-02 Thread Peter Alfredsen
On Monday 03 November 2008, Donnie Berkholz wrote:

 This eclass needs to do the same thing as the other eclasses that got
 EAPI=2 patches and default EAPI to 0 when it's not defined,
 everywhere where it tests the value of EAPI.

Yes, that makes sense, though grepping for EAPI in eclass/ shows me that 
not all chose that approach.

Updated patch attached.



-- 
/PA
--- /usr/portage/eclass/base.eclass	2008-07-17 12:06:27.0 +0200
+++ base.eclass	2008-11-03 06:57:10.0 +0100
@@ -2,32 +2,78 @@
 # Distributed under the terms of the GNU General Public License v2
 # $Header: /var/cvsroot/gentoo-x86/eclass/base.eclass,v 1.34 2008/07/17 09:49:14 pva Exp $
 
 # @ECLASS: base.eclass
 # @MAINTAINER:
-# ???
+# Peter Alfredsen [EMAIL PROTECTED]
 #
 # Original author Dan Armak [EMAIL PROTECTED]
 # @BLURB: The base eclass defines some default functions and variables.
 # @DESCRIPTION:
 # The base eclass defines some default functions and variables. Nearly
 # everything else inherits from here.
+#
+# NOTE: You must define EAPI before inheriting from base, or the wrong functions
+# may be exported.
 
 
 inherit eutils
 
+case ${EAPI:-0} in
+	2)
+		EXPORT_FUNCTIONS src_unpack src_prepare src_configure src_compile src_install
+		;;
+	*)
+		EXPORT_FUNCTIONS src_unpack src_compile src_install
+		;;
+esac
+
 DESCRIPTION=Based on the $ECLASS eclass
 
 # @FUNCTION: base_src_unpack
 # @USAGE: [ unpack ] [ patch ] [ autopatch ] [ all ]
 # @DESCRIPTION:
 # The base src_unpack function, which is exported. If no argument is given,
-# all is assumed.
+# all is assumed if EAPI!=2, unpack if EAPI=2.
 base_src_unpack() {
 
 	debug-print-function $FUNCNAME $*
-	[ -z $1 ]  base_src_unpack all
+
+	if [ -z $1 ]
+	then
+		case ${EAPI:-0} in
+			2)
+base_src_util unpack
+;;
+			*)
+base_src_util all
+;;
+		esac
+	else
+		base_src_util $1
+	fi
+}
+
+# @FUNCTION: base_src_prepare
+# @DESCRIPTION:
+# The base src_prepare function, which is exported when EAPI=2. Performs
+# base_src_util autopatch.
+base_src_prepare() {
+
+	debug-print-function $FUNCNAME $*
+
+	base_src_util autopatch
+}
+
+# @FUNCTION: base_src_util
+# @USAGE: [ unpack ] [ patch ] [ autopatch ] [ all ]
+# @DESCRIPTION:
+# The base_src_util function is the grunt function for base src_unpack
+# and base src_prepare.
+base_src_util() {
+
+	debug-print-function $FUNCNAME $*
 
 	cd ${WORKDIR}
 
 	while [ $1 ]; do
 
@@ -57,28 +103,62 @@
 done
 			fi
 			;;
 		all)
 			debug-print-section all
-			base_src_unpack unpack autopatch
+			base_src_util unpack autopatch
 			;;
 		esac
 
 	shift
 	done
 
 }
 
+# @FUNCTION: base_src_configure
+# @DESCRIPTION:
+# The base src_prepare function, which is exported when EAPI=2. Performs
+# base_src_work configure.
+base_src_configure() {
+
+	debug-print-function $FUNCNAME $*
+
+	base_src_work configure
+}
+
 # @FUNCTION: base_src_compile
 # @USAGE: [ configure ] [ make ] [ all ]
 # @DESCRIPTION:
 # The base src_compile function, which is exported. If no argument is given,
-# all is asasumed.
+# all is assumed if EAPI!=2, make if EAPI=2.
 base_src_compile() {
 
 	debug-print-function $FUNCNAME $*
-	[ -z $1 ]  base_src_compile all
+
+	if [ -z $1 ]
+	then
+		case ${EAPI:-0} in
+			2)
+base_src_work make
+;;
+			*)
+base_src_work all
+;;
+		esac
+	else
+		base_src_work $1
+	fi
+}
+
+# @FUNCTION: base_src_work
+# @USAGE: [ configure ] [ make ] [ all ]
+# @DESCRIPTION:
+# The base_src_work function is the grunt function for base src_configure
+# and base src_compile.
+base_src_work() {
+
+	debug-print-function $FUNCNAME $*
 
 	cd ${S}
 
 	while [ $1 ]; do
 
@@ -91,11 +171,11 @@
 			debug-print-section make
 			emake || die died running emake, $FUNCNAME:make
 			;;
 		all)
 			debug-print-section all
-			base_src_compile configure make
+			base_src_work configure make
 			;;
 	esac
 
 	shift
 	done
@@ -129,7 +209,5 @@
 
 	shift
 	done
 
 }
-
-EXPORT_FUNCTIONS src_unpack src_compile src_install


signature.asc
Description: This is a digitally signed message part.