Hi,
I did not write complicated script with aptitude but I use long 1 liner
search in commandline often. So feature change is concern to me.
On Tue, Apr 15, 2008 at 07:13:30AM -0700, Daniel Burrows wrote:
> Hello list,
>
> I'd like to get a feel for how people use "aptitude search".
>
> # Background #
>
> 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.
>
> 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.
Changing default behavior on bare strings seems minor problem to me.
I thought thare are 3 simple uses for old search patterns:
1. aptitude search blah
2. aptitude search ~nblah
3. aptitude search ~dblah
1 and 2 are the same result now.
If you want to make
aptitude search blah
acts as:
aptitude search "~nblah|~dblah"
You need to tell in NEWS file that local scripts need to add "~n" before
serch string to make it act as before under the new version.
"?name(blah)": is this your new syntax? Yes I see it now in manpage.
I do not like this one since "?" is used as metacharacter for regex in
ERE. Aptitude is extended ERE as I understand before you aded this.
The extension was "~". When did you add this? Why did not you chose
sequence like "~?name(blah)" as long expression. Then ? is clearly not
part of ERE expression. For example, "~ddpkg~ndpkg" is good pattern but
"~ddpkg?name(dpkg)" can not be parsed correctly.
(Is this what mutt does too? I never used mutt regrex much...)
> # 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.
Impolite... maybe if you did not announce. But if you have that
announced for lenny, doing so for lenny+1 is fine.
(Did you do that for new "?" syntax? Was this hidden feature?)
> 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.
I think that will be confusing ... too.
If what you are thinking is such simple one, NEWS with advanced notice
is enough for me.
> 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.
I think it is good idea even now.
> # 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?
Not me as I said.
I will appreciate lenny last update to include README or README.Debian
stating pending feature change (possibly in manpage too.)
Then with NEWS for lenny+1, you should be OK. I am sure you have few
more upload with new translation etc. You can add this kind of
documentation change then.
Osamu
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
