Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 55708 (debug-eclass) - debug.eclass breaks QA
Summary: debug.eclass breaks QA
Alias: debug-eclass
Product: Portage Development
Classification: Unclassified
Component: Core - Ebuild Support (show other bugs)
Hardware: All All
: High normal (vote)
Assignee: Gentoo Quality Assurance Team
: 42500 46509 79481 156816 (view as bug list)
Depends on: 160086 160087 160089 160090 160091 160092 160093 160094 160095 160096 160097 160098 160099 160100 160101 160102 160103 160104 160105 160106 160107 160108 160110 160111 160112 160113 160114 160115 160116 160117 160118 160119 160120 160121 160122 160123
Blocks: 157080
  Show dependency tree
Reported: 2004-06-30 12:24 UTC by Brian Harring (RETIRED)
Modified: 2007-03-15 09:10 UTC (History)
14 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Brian Harring (RETIRED) gentoo-dev 2004-06-30 12:24:16 UTC
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
Comment 1 foser (RETIRED) gentoo-dev 2004-06-30 15:25:40 UTC
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.
Comment 2 Brian Harring (RETIRED) gentoo-dev 2004-07-01 18:06:20 UTC
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
Comment 3 Brian Harring (RETIRED) gentoo-dev 2004-07-01 18:09:34 UTC
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 :)
Comment 4 Brian Harring (RETIRED) gentoo-dev 2004-07-10 17:24:19 UTC
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.
Comment 5 Spider (RETIRED) gentoo-dev 2004-07-11 06:49:48 UTC
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 
Comment 6 foser (RETIRED) gentoo-dev 2004-07-11 09:31:04 UTC
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.
Comment 7 Brian Harring (RETIRED) gentoo-dev 2004-07-13 14:14:24 UTC
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)

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 :)
Comment 8 Mike Gardiner (RETIRED) gentoo-dev 2004-07-22 22:40:33 UTC
o, 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().
Comment 9 Donnie Berkholz (RETIRED) gentoo-dev 2004-07-23 01:41:07 UTC 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.
Comment 10 Brian Harring (RETIRED) gentoo-dev 2004-07-24 07:16:12 UTC
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 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* .  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.
Comment 11 Donnie Berkholz (RETIRED) gentoo-dev 2004-07-24 16:22:44 UTC
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.
Comment 12 foser (RETIRED) gentoo-dev 2004-08-02 17:54:14 UTC
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.
Comment 13 Brian Harring (RETIRED) gentoo-dev 2004-08-02 18:48:10 UTC
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.
Comment 14 Mike Gardiner (RETIRED) gentoo-dev 2004-08-02 20:28:32 UTC
foser, my 'fixes' were limited to removing sed/awk from the global scope, replacing them with bash regexs.
Comment 15 Jason Stubbs (RETIRED) gentoo-dev 2004-08-03 04:26:39 UTC
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.
Comment 16 foser (RETIRED) gentoo-dev 2004-08-03 06:05:15 UTC
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.
Comment 17 Jason Stubbs (RETIRED) gentoo-dev 2004-08-03 06:48:29 UTC
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 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.
Comment 18 Marius Mauch (RETIRED) gentoo-dev 2004-08-03 10:59:50 UTC
*** Bug 55977 has been marked as a duplicate of this bug. ***
Comment 19 Nicholas Jones (RETIRED) gentoo-dev 2004-10-22 08:47:56 UTC
Bug has been fixed and released in stable portages on or before 2.0.51-r2
Comment 20 Jason Stubbs (RETIRED) gentoo-dev 2005-05-16 06:33:52 UTC
*** Bug 46509 has been marked as a duplicate of this bug. ***
Comment 21 Jason Stubbs (RETIRED) gentoo-dev 2005-05-16 06:34:03 UTC
*** Bug 79481 has been marked as a duplicate of this bug. ***
Comment 22 Jason Stubbs (RETIRED) gentoo-dev 2005-05-16 06:37:52 UTC
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.
Comment 23 foser (RETIRED) gentoo-dev 2005-05-25 16:18:06 UTC
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 ?
Comment 24 Jason Stubbs (RETIRED) gentoo-dev 2005-05-27 08:27:15 UTC
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.) 
Comment 25 Gregorio Guidi (RETIRED) gentoo-dev 2005-06-10 09:16:19 UTC
*** Bug 42500 has been marked as a duplicate of this bug. ***
Comment 26 foser (RETIRED) gentoo-dev 2005-08-01 16:17:15 UTC
I renamed it to 'debuginfo', if everyone is ok with that then it should be added
to use.desc & can this be closed.
Comment 27 foser (RETIRED) gentoo-dev 2005-08-01 16:48:56 UTC
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.
Comment 28 devsk 2005-08-01 17:32:58 UTC
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.
Comment 29 SpanKY gentoo-dev 2005-08-01 19:24:45 UTC
this bug cant really be closed until debug.eclass is gone
Comment 30 Jason Stubbs (RETIRED) gentoo-dev 2005-08-02 04:02:53 UTC
Ack on comment #28 
Comment 31 Jason Stubbs (RETIRED) gentoo-dev 2005-08-02 04:13:36 UTC
This doesn't depend on per-package FEATURES either as per comment #28. 
Comment 32 Jason Stubbs (RETIRED) gentoo-dev 2005-08-02 04:23:11 UTC
I looked for dev-portage on the CC but couldn't find it. :/ 
Comment 33 Jakub Moc (RETIRED) gentoo-dev 2006-12-01 08:11:58 UTC
*** Bug 156816 has been marked as a duplicate of this bug. ***
Comment 34 Diego Elio Pettenò (RETIRED) gentoo-dev 2007-01-04 21:04:30 UTC
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.