| 1 |
On 03/01/13 00:41, Pacho Ramos wrote: |
| 2 |
> What is the purpose of this stuff: |
| 3 |
> if [[ ${___ECLASS_ONCE_EUTILS} != "recur -_+^+_- spank" ]] ; then |
| 4 |
> ___ECLASS_ONCE_EUTILS="recur -_+^+_- spank" |
| 5 |
> |
| 6 |
|
| 7 |
I don't know exactly sure if this is the source of some recent problems, |
| 8 |
but I assume it is. |
| 9 |
|
| 10 |
While fixing some issues, I found a worrisome abnormally. |
| 11 |
|
| 12 |
$ diff -uarN tcl-8.5.13-r* |
| 13 |
--- tcl-8.5.13-r1.ebuild 2013-01-09 09:05:09.342608806 +0100 |
| 14 |
+++ tcl-8.5.13-r2.ebuild 2013-01-09 09:05:06.132529434 +0100 |
| 15 |
@@ -4,7 +4,7 @@ |
| 16 |
|
| 17 |
EAPI=4 |
| 18 |
|
| 19 |
-inherit versionator autotools eutils flag-o-matic multilib toolchain-funcs |
| 20 |
+inherit autotools eutils flag-o-matic multilib toolchain-funcs versionator |
| 21 |
|
| 22 |
MY_P="${PN}${PV/_beta/b}" |
| 23 |
|
| 24 |
|
| 25 |
Only _non_ phase function exporting eclasses are used, so the order of |
| 26 |
inheriting shouldn't matter. As you can see the only difference is the |
| 27 |
place of the versionator.eclass during inheriting. As an result the |
| 28 |
package builds completely different. Following diff can be seen during |
| 29 |
configuration: |
| 30 |
|
| 31 |
--- tcl-8.5.13-r1/temp/build.log |
| 32 |
+++ tcl-8.5.13-r2/temp/build.log |
| 33 |
|
| 34 |
checking whether to use symlinks for manpages... no |
| 35 |
checking whether to compress the manpages... no |
| 36 |
checking whether to add a package name suffix for the manpages... no |
| 37 |
checking for x86_64-pc-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc |
| 38 |
+checking whether the C compiler works... yes |
| 39 |
checking for C compiler default output file name... a.out |
| 40 |
-checking whether the C compiler works... yes |
| 41 |
+checking for suffix of executables... |
| 42 |
checking whether we are cross compiling... no |
| 43 |
-checking for suffix of executables... |
| 44 |
checking for suffix of object files... o |
| 45 |
checking whether we are using the GNU C compiler... yes |
| 46 |
checking whether x86_64-pc-linux-gnu-gcc accepts -g... yes |
| 47 |
-checking for x86_64-pc-linux-gnu-gcc option to accept ANSI C... none needed |
| 48 |
+checking for x86_64-pc-linux-gnu-gcc option to accept ISO C89... none |
| 49 |
needed |
| 50 |
checking for inline... inline |
| 51 |
checking how to run the C preprocessor... x86_64-pc-linux-gnu-gcc -E |
| 52 |
-checking for egrep... grep -E |
| 53 |
+checking for grep that handles long lines and -e... /bin/grep |
| 54 |
+checking for egrep... /bin/grep -E |
| 55 |
checking for ANSI C header files... yes |
| 56 |
checking for sys/types.h... yes |
| 57 |
checking for sys/stat.h... yes |
| 58 |
|
| 59 |
|
| 60 |
The changes are small but the shouldn't be there at all, as the ebuilds |
| 61 |
are completely equal except for the inheriting order. |
| 62 |
|
| 63 |
Also the internals of the build are affected (probably through the |
| 64 |
difference in configure). This leads to disrespected LDFLAGS and broken |
| 65 |
tclConfig.sh. So this simple change has deep consequences. |
| 66 |
|
| 67 |
|
| 68 |
My question, did anybody else might have observed similar things? Is |
| 69 |
there a flaw in this *ECLASS_ONCE_* stuff? |
| 70 |
|
| 71 |
Thanks, |
| 72 |
Justin |
Archives