There are lots of ebuilds forgetting to even set GCONF_DEBUG and, then, leading to a "debug" flag being added even if they don't have "--enable-debug" toggle, but they are hard to catch because the configure option is passed only when debug USE if enabled Attached patch adds a check for fixing this cases Reproducible: Always
Created attachment 349900 [details, diff] 1.patch
I have just seen this case -> gnome-bluetooth-3.8.1 It has GNOME_DEBUG_CHECK in configure.ac... but it leads to a normal --enable/disable-debug (without yes/no/minimum). What needs to be done in that cases? Set GCONF_DEBUG="no" and handle it normally? (with $(use_enable debug))
(In reply to Pacho Ramos from comment #2) > I have just seen this case -> gnome-bluetooth-3.8.1 > > It has GNOME_DEBUG_CHECK in configure.ac... but it leads to a normal > --enable/disable-debug (without yes/no/minimum). What needs to be done in > that cases? Set GCONF_DEBUG="no" and handle it normally? (with $(use_enable > debug)) I guess that it should handle it manually and, instead, if we decide to keep GCONF_DEBUG for the "special" handling, it should either pass --enable-debug or --enable-debug=minimum. That way we also catch the (many) packages that shouldn't really use this switch
Well, as this cannot be really done, better wait for rethinking all this debugging stuff in bug 270919 (hopefully for eapi6) *** This bug has been marked as a duplicate of bug 270919 ***
I have a patch laying somewhere to add eqawarn when the variable is unset. Of course, this EAPI bump is a nice way to act on it too.