Re: Question about how "aptitude search" is used
On Tue, Apr 15, 2008 at 09:58:27AM -0500, "Mumia W.." <paduille.4061.mumia.w+nospam@earthlink.net> was heard to say:
> On 04/15/2008 09:13 AM, Daniel Burrows wrote:
> I like the current default behavior for bare strings.
While I hope this goes without saying, there will probably be a
configuration option to disable this for people who dislike it. (there,
now when I forget to implement it you can beat me over the head with
this email. :-) )
> I'm not using it in a script yet, but the default behavior of 'aptitude
> search' always made more sense to me that the default behavior of
> 'apt-cache search.' I'm almost always looking for package name
> substrings, and when I do decide to search within descriptions, I'm not
> usually concerned with searching on the package names.
>
> Anyway, for those few times when I need to search for a substring in
> both the package name and description, 'apt-cache search' is always
> available. Aptitude doesn't need to become a replica of apt-get.
In my opinion, a package manager has two basic functions:
(a) help the user find the packages he/she wants
(b) help the user manage the state of packages on his or her system
aptitude has always been strong on point (b), IMO, and I've mostly
spent the last few years improving it even more. But its handling of
the "help me find a package" question is, to put it bluntly, utter and
complete suckage -- unless, that is, you happen to know part of the name
of the package you want to find.
I hope to improve this significantly in future releases[0], and one of
the things that I want to fix is the behavior of "aptitude search". This
isn't the only thing, but it will be a natural place to expose some of
the functionality I'm thinking about adding.
Searching on package names is useful, of course, but you will always
be able to request it directly; what I'm discussing here is just about
what a search for a bare string without any context does.
This isn't about imitating apt-cache. This is more about improving an
area of historical weakness for aptitude and hopefully surpassing
apt-cache by a wide margin.
Daniel
[0] Note: if I implement it and decide I hate the result, I reserve
the right to change my mind and abandon the new code. ;-)
Reply to: