gnome2.eclass is missing doc in IUSE but is using it: <snip> # doc keyword for gtk-doc G2CONF="${G2CONF} $(use_enable doc gtk-doc)" <snip> Which produces "QA Notice: USE Flag 'doc' not in IUSE" for ebuilds that inherit gnome2.eclass Reproducible: Always Steps to Reproduce:
Any reason not to add this team?
Please, fix this trivial bug. Thanks.
*** Bug 101118 has been marked as a duplicate of this bug. ***
The eclass used to have 'doc' in IUSE, but for some reason foser removed it (CVS revision 1.55). Foser?
*** Bug 116090 has been marked as a duplicate of this bug. ***
Not every gnome2 eclass using ebuild has optional docs to be built, having the IUSE=doc in the eclass would suggest they have. So it is really up to the seperate ebuilds to define the flag only if it is really used. The QA notice is flawed for this use-case.
(In reply to comment #6) > Not every gnome2 eclass using ebuild has optional docs to be built, having the > IUSE=doc in the eclass would suggest they have. So it is really up to the > seperate ebuilds to define the flag only if it is really used. > > The QA notice is flawed for this use-case. <ebuild snip> HAVE_GTK_DOC="yes" </ebuild snip> <eclass snip> IUSE="debug" if [[ ${HAVE_GTK_DOC} == "yes" ]] ; then IUSE="${IUSE} doc" fi ... # doc keyword for gtk-doc if [[ ${HAVE_GTK_DOC} == "yes" ]] ; then G2CONF="${G2CONF} $(use_enable doc gtk-doc)" fi </eclass snip> Possible solution, but might be too many ebuilds to change, perhaps?
Quite a few. I personally think QA warnings are nothing more than indicators that something might be wrong, not that something is wrong. As such I don't really feel a need to 'fix' this, I don't think the warnings should be exposed to the general user anyway. As a possible solution, rather than adding another env. var. we could make the IUSE optional based on a quick scan of configure.in . I'm not sure if thats frowned upon as bad behaviour for eclasses ?
(In reply to comment #8) > Quite a few. I personally think QA warnings are nothing more than indicators > that something might be wrong, not that something is wrong. As such I don't > really feel a need to 'fix' this, I don't think the warnings should be exposed > to the general user anyway. Shrug, you'll need to discuss the warning stuff w/ portage guys mostly likely. :) > As a possible solution, rather than adding another env. var. we could make the > IUSE optional based on a quick scan of configure.in . I'm not sure if thats > frowned upon as bad behaviour for eclasses ? This sounds kinda like a hack, better to ignore the QA notice altogether then. My understanding is that use flags need to be shown to users at emerge -p time, no way to achieve this with the above suggestion (whether it's allowed or not). Considering that there are ebuilds in the tree, that inherit bogus use flags from KDE eclasses and show them to users even that they are not honored later on, the thing this bug is about is really a cosmetic issue.
(In reply to comment #9) > > As a possible solution, rather than adding another env. var. we could make the > > IUSE optional based on a quick scan of configure.in . I'm not sure if thats > > frowned upon as bad behaviour for eclasses ? > > This sounds kinda like a hack, better to ignore the QA notice altogether then. > My understanding is that use flags need to be shown to users at emerge -p time, > no way to achieve this with the above suggestion (whether it's allowed or not). Right, i wasn't thinking straight :) I'll poke some portage maintainer about it.
*** Bug 136604 has been marked as a duplicate of this bug. ***
*** Bug 145956 has been marked as a duplicate of this bug. ***
(In reply to comment #7) > # doc keyword for gtk-doc > if [[ ${HAVE_GTK_DOC} == "yes" ]] ; then > G2CONF="${G2CONF} $(use_enable doc gtk-doc)" > fi > </eclass snip> > > Possible solution, but might be too many ebuilds to change, perhaps? What about this: 1. don't change IUSE in the eclass 2. snip above would look like this: # doc keyword for gtk-doc if [[ (have doc in IUSE) ]] ; then G2CONF="${G2CONF} $(use_enable doc gtk-doc)" fi I don't know how to do the doc-IUSE check exactly, but it should be possible using hasq or something similar.
(In reply to comment #13) > 1. don't change IUSE in the eclass > 2. snip above would look like this: > > # doc keyword for gtk-doc > if [[ (have doc in IUSE) ]] ; then > G2CONF="${G2CONF} $(use_enable doc gtk-doc)" > fi Read Comment #6 please... Also, the above is just redundant code, doesn't change anything from current behaviour, and doesn't fix the QA notice either.
(In reply to comment #14) > Read Comment #6 please... Also, the above is just redundant code, doesn't > change anything from current behaviour, and doesn't fix the QA notice either. Why do you think so? Comment #6 states (as I understand it) that it's not good solution to add doc to IUSE in the eclass and that it's up to ebuilds to do it. So, possible fixes are: - move the $(use_enable doc gtk-doc) to ebuilds - don't check for doc USE unless it's in IUSE (my solution from Comment #13) - ignore the issue (why not resolve bug as WONTFIX then?)
(In reply to comment #15) > Why do you think so? Comment #6 states (as I understand it) that it's not good > solution to add doc to IUSE in the eclass and that it's up to ebuilds to do it. Because it will _still_ leave all other ebuilds that inherit gnome2.eclass spit out the QA notice. > So, possible fixes are: > - move the $(use_enable doc gtk-doc) to ebuilds > - don't check for doc USE unless it's in IUSE (my solution from Comment #13) > - ignore the issue (why not resolve bug as WONTFIX then?) Won't solve anything, that's not how IUSE and this check works (see above).
If the eclass uses the "doc" USE flag then it needs IUSE="doc". END OF STORY It is NOT up to ebuilds to add "doc" to their USE flags. That is WRONG and broken. I will CC the QA team on this.
Created attachment 102475 [details, diff] patch against gnome2.eclass This is the solution that other eclasses use: <snip from betelgeuse@pena /usr/portage/eclass $ grep IUSE * | grep has> java-utils-2.eclass: if hasq jikes ${IUSE}; then java-vm-2.eclass: if has nsplugin ${IUSE} && use nsplugin; then kde.eclass: if hasq kdeenablefinal ${IUSE}; then kde.eclass: if hasq kdehiddenvisibility ${IUSE} && use kdehiddenvisibility; then pam.eclass: if hasq pam ${IUSE} && ! use pam; then pam.eclass: if hasq pam ${IUSE} && ! use pam; then
Though foser is right, the patch has been applied, lets hope thats the end of this never-ending bug.
