As already reported to dev-ml. $ diff -uarN tcl-8.5.13-r* --- tcl-8.5.13-r1.ebuild 2013-01-09 09:05:09.342608806 +0100 +++ tcl-8.5.13-r2.ebuild 2013-01-09 09:05:06.132529434 +0100 @@ -4,7 +4,7 @@ EAPI=4 -inherit versionator autotools eutils flag-o-matic multilib toolchain-funcs +inherit autotools eutils flag-o-matic multilib toolchain-funcs versionator MY_P="${PN}${PV/_beta/b}" Only _non_ phase function exporting eclasses are used, so the order of inheriting shouldn't matter. As you can see the only difference is the place of the versionator.eclass during inheriting. As an result the package builds completely different. Following diff can be seen during configuration: --- tcl-8.5.13-r1/temp/build.log +++ tcl-8.5.13-r2/temp/build.log checking whether to use symlinks for manpages... no checking whether to compress the manpages... no checking whether to add a package name suffix for the manpages... no checking for x86_64-pc-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc +checking whether the C compiler works... yes checking for C compiler default output file name... a.out -checking whether the C compiler works... yes +checking for suffix of executables... checking whether we are cross compiling... no -checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether x86_64-pc-linux-gnu-gcc accepts -g... yes -checking for x86_64-pc-linux-gnu-gcc option to accept ANSI C... none needed +checking for x86_64-pc-linux-gnu-gcc option to accept ISO C89... none needed checking for inline... inline checking how to run the C preprocessor... x86_64-pc-linux-gnu-gcc -E -checking for egrep... grep -E +checking for grep that handles long lines and -e... /bin/grep +checking for egrep... /bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes The changes are small but the shouldn't be there at all, as the ebuilds are completely equal except for the inheriting order. Also the internals of the build are affected (probably through the difference in configure). This leads to disrespected LDFLAGS and broken tclConfig.sh. Do you need more informations?
Judging from the default settings near the top of multilib.eclass (CFLAGS, LDFLAGS, and others), it's possible that order could matter if there's interference with one or more of the other inherited eclasses.
Long story short, patching configure AND configure.in/ac is a bad thing.
