both gnome2 and gst-plugins have code of this sort- use debug && inherit debug See bug #35837 for the portage dev's previous ruling on conditional inherits- summarizing, it breaks eclass_cache, resulting in portage not always knowing that the ebuild uses that class, so portage won't update the ebuild when the eclass changes. Realworld example would be if I added to the debug class support for a profiling use flag; w/ *all* gnome2/gst-plugins, portage would be unable to detect the need to update those ebuilds due to the eclass changing, so rsynced cache's would no longer be valid. In this particular case, just inherit debug. debug.eclass already does the useq check- no point in having the equivalent of if use debug; then if use debug; then ....
well actually i think this already happened by carpaskis changing it to a USE driven eclass. Personally i think this basic debugging stuff should not be flagged that way, the USE debug is for optional debug support in packages, not for general 'make a package compilation safe for gdb' type of setting. In another sense that change fixes the conditional inherit (i suppose that was the thought behind it), but i think the correct fix would be to get rid of the debug eclass and make that sort of debugging basics part of portage functionality. And then we could get nicely rid of the conditional inherit statements.
While this functionality may be included into portage down the line, making INHERITED conditonally set isn't valid now- Main thing this bug was after was getting the use debug && inherit debug syntax
Crap. ctrl+a functions a bit differently in safari then it does on my home linux machine, pardon the crud post above :/ Finishing up the earlier statement, main thing I'm after is getting that syntax removed, and having the class inherit debug explicitly rather then conditionally. Moving the debug/RESTRICT="nostrip" functionality into portage would make sense, but I'd wonder about it being implemented in .51- .51 I would think is getting rather close to being pushed out (carpaski would be able to answer that much better of course). Either way, w/ the current portage versions available, it's invalid :)
Including debug functionality into portage is a seperate bug (and should be filed as such). This bug was originally filed as a QA issue w/ gnome and gst-plugins, and that's what this bug should be left as. Again, there is no reason for that conditional inheritance, and it violates QA policies. Please correct it.
as the debug eclass doesn't break anything if the debug flag is unset (it should be moved to flag-o-matic , "filter-flags -fomit-frame-pointer" "append-flags -g" though. removing the conditional inherit from gnome2.eclass
The problem i have with the solution that is pushed here is that it implies a debug USE flag to every package that inherits these eclasses, while this is implemented in a way that it doesn't actually mean anything on a per-package basis (we don't implement debug functionality in every ebuild and it isn't even possible most of the time). That is why this should not be implemented this way and portage should take care of this functionality. That's why i moved it on. Thats why i want the portage devs here to reply to this & make a statement. This is not a QA issue: this has been a know & working solution for ages, only now repoman starts to complain it has become an issue to some. We knew what we we're doing here and why. It is _not_ harmful, it only bends the rules a little. In short, if this gets fixed in portage i'm fine with removing the conditional inherits and debug eclass (they lost their purpose). Until that time I personally see no reason to change the behaviour for the reason stated above, it works, it is not harmful, it is better feedback to the user. It is only repoman that complains without a real cause here.
Repoman isn't capable of detecting it (only aliz's script is afaik). I came across it when I was doing an audit's of the eclasses and noticed it :) As for it being a working solution, again, it may work now, but the rule exists for a reason. Cond. inherits *allow* for breakage in the rsync eclass cache, potentially pissing off a lot of rsync users. I'd think probably taking the discussion of how to implement debug'ing for ebuilds (as a portage/flag-o-matic default) probably should be taken to the -dev mailing list; whatever solution they end up w/ I'd be willing to look into implementing. Meanwhile, since I've got your attention, the usage of sed/awk/pkg-config in the global scope in gst-plugins, gtk-engines, gtk-engines2 ought to be removed. For the sed usage, just use bash's regex. Usually it's of this sort- PVP="$(echo " $PV " | sed 's:[-\._]: :g')" which can be easily converted to PVP="${PV/[-._]/ }" avoiding the sed usage. The sed usage has a pretty noticable impact on a full regen. The awk usage in gtk-engines @ line 144, assuming I'm reading it correctly, is just getting the first char of MY_PN. You can get the first char via a bash trick- ${MY_PN:0:1} (var,offset,len) or, SRC_URI="http://ftp.debian.org/debian/pool/main/${MY_PN:0:1}/${MY_PN}/${MY_PN}_${PV}.orig.tar.gz" Moving the pkg-config out of the global scope in gtk-engines2 I'm not sure about- this seems like an instance where an equivalent to pkg_setup would be useful for eclasses. With those addressed, I'll shut up and leave y'all alone :)
o gnome.org, gst-plugins and gtk-engines eclasses have been fixed. o gtk-engines2.eclass still needs fixing for removing pkg-config from the global scope, but as noted previously, requires bigger rewrites, perhaps utilising a pkg_setup().
http://dev.gentoo.org/~spyderous/scripts/grab_ver is a little script that'll turn a best_version thing into a version number. With slight modification, it could be easily made an eclass function.
Spyderous- I could see adding this to portageq actually. I'm well aware that portageq calls are quite slow (around .5 second each), but related to my work in bug #56408, I've created a daemonized ebuild.sh processor- while that speeds things up, one of the nifty tricks that came out of it was a way to basically hijack portageq calls (any calls really), and have the current portage process handle it. Vasically we could do portageq split_ver "xyz", w/ my hijack, it has the actual portage function process it, returning it into the bash env. All of the relevant files are in http://dev.gentoo.org/~ferringb/ebuild-daemon/* . Personally, I'd think accessing the existing functions rather then doing a duplicate bash script is the way to go- it's contingent on A) bug #56408 being included, B) the ebuild-daemon patches being included. In the meantime, portageq could be extended to support it, it just would be slow. Thoughts? Sounds like a pipe dream I realize, but A will be included at some point, and B should be for it's speed gains- on my system it drops a regen from 32 minutes to 22 minutes roughly.
Yeah, it would be better in portageq -- could it be in portage proper though as well? I wrote that stuff as more of an exercise, pending something more useful. gmsoft already topped mine with some sed-fu.
don't go offtopic I personally left the stuff in this way to get some attention (and obz unknowningly 'fixed' it) because it as broken now as it was before. The portage cache is broken because it doesn't allow for these logical constructions & the fact that we have debug in USE in every single gnome package now is broken behaviour as well. I was aware of the possible problems & they were no problem in this case, so there was nothing to fix except warnings by secondairy scripts. I'd like a solid solution not some hackish workaround we have now (one way or the other). I'm afraid this ends like so many other issues on the bottom of the big portage todo pile like so many basic functionality has been for so long, while way less urgent stuff gets in because it's tremendously pushed. I'm not happy those eclasses got 'fixed' (read : 'work around portage deficiencies') , i'm not happy with the workaround solution in the debug eclass itself. This is feature level behaviour and should've been in portage from day 1. I have no clue why there is no straightforward way to get users to create usable backtraces, especially now our userbase is seriously degrading knowledgewise. In my earlier comments I implied I only wanted to change the eclass if the portage functionality actually was there, but i see the pressure got to my fellow devs. Please do tackle this issue asap. What worries me most is that despite the amount of discussion here there still hasn't been a portage dev that replied. So much for the todo.
Foser, *I'm* a portage dev. I'll address the rest of your comment later, but I'd like to point out that this conditional inherit 'deficiency' only seems to be hindering your eclasses; every other eclass abides by the rules. Also, there is no excuse for leaving sed/pkg-config/awk calls in global scope. It's inefficient. If you want something changed in portage, fine, file a bug. Don't just go ignoring it because you don't think it's right. Behaviour like that breaks things for the users, while those who *could* make the changes are oblivious to what you want. Besides that, you're forgetting that implementing debug as a feature is tied to a portage release- in the interim, the rules still must be abided until the code is in actual use.
foser, my 'fixes' were limited to removing sed/awk from the global scope, replacing them with bash regexs.
Seeing as I'm getting these mails twice, I'll answer on both counts. On behalf of qa, breaking or even bending any portage rules is bad. In this case, users get misinformation when --pretend'ing an emerge. Whether debug should be intrinsic to portage or not, users know it not to be and are misled if a debug does not appear in the USE flags. Similarly, portage is misled and does not add any required dependencies that might be if debug is set. On behalf of dev-portage, breaking or even bending any portage rules is bad. Unless a specific bug is filed requesting a feature, it won't be done. Breaking the rules only means that we have to implement all sorts of tricks and hacks when adding new functionality so as to not break half the tree when it is released, which of course only makes it take longer before your feature request is implemented.
the actual way it was done breaks nothing at all, that is the whole point. Only portage now complains about it so only now ppl complain to us. This whole thread is about something that isn't actually a problem in any way. The current 'solution' is as much bending rules QA wise as it was before, it bends the meaning of the debug USE flag. That is a QA issue that has been introduced by carpaski 'fixing' the debug eclass. QA issues one way or the other. The problem with the cache is a portage problem, not ours. A mere logical construction is not working correctly because of portage deficiencies, if you make hacks for portage bugs to be the rule then there's a world of pain ahead. This point of this bug is to tackle the problem by it's root, not implement hacks all around the tree. As far as removing dev-portage from CC, it's a sign on the wall. Sorry if I have my doubts about filing bugs for portage features/bugs, i'm CC-ed on some major core feature requests that have been open for years now. As i see it the only way that seems to get things done is to pressure the portage team on IRC, at least that is what i see other devs do to get their nitwit features in. I'll let it go, I'm tired of hoping for some serious unbiased reply from the portage team that actually does see the problem where it is and doesn't opt for short-term hacks to make it go away. I'll just remove the inherit debug from all the eclasses, I'm happy.. you are happy.. all is good. I'll tell users to edit ebuilds & add 'inherit debug' every time they need to get a usable backtrace for us or tell them to set nostrip here, filter their CFLAGS there and so on.
I'd never actually looked at the debug eclass before. It's tiny but breaks half a dozen rules in and of itself. Brian, could you get that stuff into ebuild.sh with a FEATURES="debug" or something? Foser, I still you should have filed a bug separately. Just make sure to state everything clearly with complete logic and reasoning.
*** Bug 55977 has been marked as a duplicate of this bug. ***
Bug has been fixed and released in stable portages on or before 2.0.51-r2
*** Bug 46509 has been marked as a duplicate of this bug. ***
*** Bug 79481 has been marked as a duplicate of this bug. ***
Nothing was ever done to fix this, as far as I know. USE="debug" is still a baaad thing. Now it's confusing the hell out of users.
I got informed some time ago (around #19 i guess) a debug feature (?) was planned for portage and as such we could remove this hack in time. Until that time it does serve a purpose to make users have an easy way to getting us complete debug information (setting a host of make.* stuff scares users away). But judging from your comment (#22) no such thing has been done or planned ?
I can't recall why this bug was marked InCVS. Changing the USE flag to "debug-build" or something else that is not "debug" should keep everyone happy for the time being. Right now, the debug USE flag is as least as (if not more so) confusing to users as it is helpful. (I still think this hack was stupid. Educating users is too hard to we should just confuse them more? That line of thought is what has lead to all the misinformation on gentoo-wiki.)
*** Bug 42500 has been marked as a duplicate of this bug. ***
I renamed it to 'debuginfo', if everyone is ok with that then it should be added to use.desc & can this be closed.
reverted that change for now, a notorious N.E.R.D. pointed me to the fact that the eclass is by now used in situations it wasn't really meant for and that this change could give serious problems here and there.
I am reopening the bug 55977 because I think this is a FEATURE not a USE flag. The issues in this bug report have nothing to do with debug support inside of portage. Please carry on discussions about portage debug support in 55977.
this bug cant really be closed until debug.eclass is gone
Ack on comment #28
This doesn't depend on per-package FEATURES either as per comment #28.
I looked for dev-portage on the CC but couldn't find it. :/
*** Bug 156816 has been marked as a duplicate of this bug. ***
And now that nothing in the tree makes use of this eclass, we can finally close this bug. Besides, if someone had something using it in overlay, it will scream its way out.
