Re: Question about how "aptitude search" is used
On Tue, Apr 15, 2008 at 09:20:21PM -0400, "Douglas A. Tutty" <dtutty@porchlight.ca> was heard to say:
> On Tue, Apr 15, 2008 at 07:13:30AM -0700, Daniel Burrows wrote:
> > One of the things I'd like to implement in an upcoming aptitude
> > release (probably post-lenny, likely next year) is a significant
> > overhaul of the UI to the search engine; that is, how searches are
> > entered and carried out from the interface.
>
> It would be nice if there was a help screen in the curses UI that gave
> the same info as the search strings section in the html docs, save
> opening them up in lynx.
Yes, that's somewhere in the pile of mental notes I've made about
things to do in the future. Ideally the help screen would be available
as a pane in the search dialog, so you could reference it while writing
a search...
> > In the current CLI, "aptitude search blah" searches for packages
> > whose name contains "blah". In contrast, "apt-cache search blah"
> > searches both package names and descriptions. What I'd really like to
> > do is a full-text search with approximate matches on the whole package
> > index that returns packages which might be relevant to "blah", with an
> > option to sort the results by various relevance metrics. Of course,
> > "aptitude search ?name(blah)" will always be available; this is just
> > about changing the default behavior on bare strings.
>
> I've never tried to do both at once before; I'm assuming that you put in
> an "OR" operator, however why not just add a global function ~Z or
> whatever that would search for the term as a keyword in any field?
Because I think that the potential impact is relatively small (I
haven't been able to think of any actual use case for "search" in a
script, and I have yet to hear of anyone actually doing this in real
life), while the benefit of having "aptitude search" produce more useful
results is relatively large.
> > So, I'd really like to just change the default behavior of "search"
> > when it's given a bare string. If I were designing the program up-front
> > this is what I'd do, and I think it's the best end-point.
>
> Well, then I'd change the way I work and people writing scripts whould
> have to change them.
That is sort of the idea; I wanted to get a sense of what the impact
was among a small and self-selected group, rather than just operating
totally without data.
> I don't suppose while you're re-writing aptiutde you can make it not hit
> swap when I start the curses interface on my P-II with 64 MB ram (or
> will Lenny and whatever comes next not run on 64MB anyway)?
Well, that depends. I have no objection, in principle, to making the
program faster and more efficient -- as long as this doesn't come at the
expense of code clarity and maintainability in the future. I also have
fairly limited time to spend on the project, and profiling and
optimization tend to be enormous time-sinks in my experience, so I'm
reluctant to get too involved in them.
Did aptitude work on this system in past Debian releases? The only real
memory-hogging change in the program I can think of is the switch to
Unicode a few years ago; I wouldn't think off-hand that aptitude stores
enough wide strings in memory to cause this sort of behavior, but maybe
I'm wrong. Other than that, the other obvious potential culprits seem
like the increase in the number of packages in the archive and changes in
the toolchain and standard library (not that I know of anything
specifically, but if an STL component started allocating memory more
aggressively, aptitude would be affected).
Daniel
Reply to: