On 03/01/13 00:41, Pacho Ramos wrote:
> What is the purpose of this stuff:
> if [[ ${___ECLASS_ONCE_EUTILS} != "recur -_+^+_- spank" ]] ; then
> ___ECLASS_ONCE_EUTILS="recur -_+^+_- spank"
>
I don't know exactly sure if this is the source of some recent problems,
but I assume it is.
While fixing some issues, I found a worrisome abnormally.
$ 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. So this simple change has deep consequences.
My question, did anybody else might have observed similar things? Is
there a flaw in this *ECLASS_ONCE_* stuff?
Thanks,
Justin
signature.asc
Description: OpenPGP digital signature
