Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 175299 - app-portage/portage-utils: qsearch doesn't find gtkhtml-sharp
Summary: app-portage/portage-utils: qsearch doesn't find gtkhtml-sharp
Status: RESOLVED CANTFIX
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Tools (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Portage Utils Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-04-20 03:38 UTC by Jorge Manuel B. S. Vicetto
Modified: 2010-01-24 21:34 UTC (History)
1 user (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jorge Manuel B. S. Vicetto Gentoo Infrastructure gentoo-dev 2007-04-20 03:38:24 UTC
The qsearch applet, doesn't find gtkhtml-sharp.

Reproducible: Always

Steps to Reproduce:
1. qsearch gtkhtml-sharp
Actual Results:  
Empty output

Expected Results:  
It should show the available gtkhtml-sharp versions

user@host ~/ $ equery which gtkhtml-sharp
/usr/portage/dev-dotnet/gtkhtml-sharp/gtkhtml-sharp-2.16.0.ebuild
Comment 1 TGL 2007-04-20 06:20:11 UTC
I can reproduce this issue with "qsearch gtkhtml-sharp".  Using "qsearch -c gtkhtml-sharp" at the contrary works fine.  The reason is that DESCRIPTION is defined in an eclass, not the ebuild itself.

I don't see any simple way to fix that.  Making qsearch grep in the inherited eclasses would not even be enough, since here it would also need to do some bash vars evaluations:
% grep DESCR /var/portage/tree/eclass/gtk-sharp-component.eclass 
DESCRIPTION="${GTK_SHARP_COMPONENT_BUILD} component of gtk-sharp"

Maybe "qsearch -c" should simply be made the default behavior (with "q -m" being added to the rsync hook sure)?
Comment 2 solar (RETIRED) gentoo-dev 2007-04-20 20:44:30 UTC
(In reply to comment #1)
> I can reproduce this issue with "qsearch gtkhtml-sharp".
>  Using "qsearch -c
> gtkhtml-sharp" at the contrary works fine.  The reason is that DESCRIPTION is
> defined in an eclass, not the ebuild itself.

Thanks for looking into this.
 
> I don't see any simple way to fix that.  Making qsearch grep in the inherited
> eclasses would not even be enough, since here it would also need to do some
> bash vars evaluations:
> % grep DESCR /var/portage/tree/eclass/gtk-sharp-component.eclass 
> DESCRIPTION="${GTK_SHARP_COMPONENT_BUILD} component of gtk-sharp"
>
> Maybe "qsearch -c" should simply be made the default behavior (with "q -m"
> being added to the rsync hook sure)?

We can't really do that. On dev boxes we often use our CVS checkouts as PORTDIR 
and that wont ever contain a metadata/ dir, so a qsearch would end up returning 
nothing. 

Perhaps however maybe we could check if the metadata dir exists. If it does then 
default to CACHE_METADATA otherwise fallback to CACHE_EBUILD. in order to do 
that we however would need an override flag for all supporting applets that can 
use (cache || ebuilds)
Comment 3 solar (RETIRED) gentoo-dev 2007-05-12 03:19:04 UTC
Closing bug