SpanKY -- Brought this up a few months ago, just ran into it again. Best to get it filed and dealt with before I forget again The gist is if an ebuild references patch sets in both FILESDIR and WORKDIR, and say, it does WORKDIR first, then moves on to process some patches in FILESDIR, and a patch in FILESDIR is not present, or epatch is invoked wrongly (epatch && epatch <patch> did it in this case), then epatch will turn around, and attempt to re-apply patches already applied. Basically bumped into it again by trying to test a mips patch to gcc-3.4.2-r1.ebuild. If you want to try and re-create it, edit the ebuild, and after the n32/n64 patch lines in src_unpack, add some epatch call like "epatch && epatch ${FILESDIR}/blah.patch" (yes, that's a typo), and make blah.path an empty one. That, in theory, should trigger this bug I'm referring to. epatch will turn around, and attempt to re-apply the patchset it first applied after unpacking. Not exactly sure of all the possible combinations that trigger this. So far I know using epatch on a nonexistant patch does it, and the above typo also triggers it (when epatch should fail on such behavior).
Index: eutils.eclass =================================================================== RCS file: /var/cvsroot/gentoo-x86/eclass/eutils.eclass,v retrieving revision 1.122 diff -u -r1.122 eutils.eclass --- eutils.eclass 31 Oct 2004 04:34:08 -0000 1.122 +++ eutils.eclass 11 Nov 2004 03:51:46 -0000 @@ -247,7 +247,7 @@ local EPATCH_SOURCE="$1/*.${EPATCH_SUFFIX}" fi else - if [ ! -d ${EPATCH_SOURCE} ] + if [ ! -d ${EPATCH_SOURCE} ] || [ -n "$1" ] then if [ -n "$1" -a "${EPATCH_SOURCE}" = "${WORKDIR}/patch" ] then
added to cvs
