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. > 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? > # Problem # > > The problem that I see is that aptitude's current behavior is > predictable enough that people might be relying on it in home-grown > scripts. Changing the semantics of a command underneath a script is > impolite at best and will likely break things. So enhance the script language rather than changing it. > > The alternative if I decide to maintain backwards-compatibility is > to write a second command like "aptitude find" or "aptitude grok" or > what-have-you, or to add some parameters to the "search" command > (something like "--full-search"). In the first case, I get to answer > user questions about the difference between "find" and "search" until > the end of time, while in the second case, I get to answer user > questions about how to search on more than just package names until the > end of time. If its fully documented, and especially if there is an adequate help screen on search terms built-in, then just tell people to RTM. > 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. > # Question # > > How many readers of this list are using "aptitude search" as a > subcommand in a script? Will you be impacted by this change? Will > anyone else be adversely impacted despite not using it in a script? As long as you add a command to allow a search just on name (unless its there already a duplicate of no prefix), users like me will get used to it. The only search string I have in a script is my backup script which generates a list of all installed packages not automatically installed (i.e. manually installed packages). Off the top of my head its ~i!~M but I could be wrong. 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)? Doug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]