FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian User

 
 
LinkBack Thread Tools
 
Old 04-15-2008, 02:13 PM
Daniel Burrows
 
Default Question about how "aptitude search" is used

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.

# 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.

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.

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.

# 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?

Thanks,
Daniel


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 04-15-2008, 02:58 PM
"Mumia W.."
 
Default Question about how "aptitude search" is used

On 04/15/2008 09:13 AM, 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.



I like the current default behavior for bare strings.


# 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.



Correct.


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.

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.

# 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?

Thanks,
Daniel




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.



--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 04-15-2008, 03:38 PM
Osamu Aoki
 
Default Question about how "aptitude search" is used

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 debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 04-15-2008, 03:39 PM
Kamaraju S Kusumanchi
 
Default Question about how "aptitude search" is used

Daniel Burrows wrote:

> # 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?

I do not use aptitude search in a script and I am not affected by this
change. I think it would be great if "aptitude search" does what "apt-cache
search" is currently doing.

thanks
raju
--
Kamaraju S Kusumanchi
http://www.people.cornell.edu/pages/kk288/
http://malayamaarutham.blogspot.com/


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 04-15-2008, 03:55 PM
Jochen Schulz
 
Default Question about how "aptitude search" is used

Daniel Burrows:
>
> 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.

Which is the reason why I am almost exclusively using apt-cache for
searches (and probably the reason why I cannot remember aptitude's
search options, even though they are great).

> 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.

I like the full-text search idea, but I dislike the idea of approximate
matches (without it being a different command or a parameter). It makes
search results less predictable and hurts cases where your search terms
yield many results anyway.

On the other hand I have to plug this:
<http://well-adjusted.de/mspace.py/>

> 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?

I don't write many scripts for my boxes but I don't use Debian in a
commercial environment where scripting comes in handy more often. So
besides my comments above, I would not be impacted.

Another aspect you should consider is speed. Aptitude is already quite
slow and memory intensive. In my opinion, you should refrain from making
it even more unsuitable for low-end devices than it already is. It's
Debian's preferred package manager, after all.

J.
--
I am worried that my dreams pale in comparison beside TV docu-soaps.
[Agree] [Disagree]
<http://www.slowlydownward.com/NODATA/data_enter2.html>
 
Old 04-15-2008, 05:34 PM
"Kim N. Lesmer"
 
Default Question about how "aptitude search" is used

On Tue, 15 Apr 2008 07:13:30 -0700
Daniel Burrows <dburrows@debian.org> wrote:

Hi Daniel.

> 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?

I have always been annoyed with this exact problem, but I don't think
the solution you think about implementing (doing like apt-cache) is the
best way to go.

I would recommend trying to mimic something like the search function of
the FreeBSD ports system with specific options so that it is very easy
and intuitive to use and, at the same time, you can still make it
backward compatible.

Default behaviour:

>From FreeBSD:
$ make search name=foo

Aptitude:
$ aptitude search foo

OR newly added feature

$ aptitude search name=foo

>From FreeBSD:
$ make search key=bar

Wich searches both names and descriptions.

$ aptitude search key=bar

Anyway, just a thought.

>
> Thanks,
> Daniel
>
>
> --
> To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmaster@lists.debian.org
>
>


--
Med venlig hilsen/Best regards

Kim N. Lesmer
Programmer/Systems administrator

Web : www.bitflop.com
E-mail : knl@bitflop.com


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 04-16-2008, 01:20 AM
"Douglas A. Tutty"
 
Default Question about how "aptitude search" is used

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 debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 04-16-2008, 04:57 AM
Daniel Burrows
 
Default Question about how "aptitude search" is used

On Wed, Apr 16, 2008 at 12:38:46AM +0900, Osamu Aoki <osamu@debian.org> was heard to say:
> 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.

My question was: are there any such local scripts? It seems possible
to me that someone might have written a script that uses aptitude this
way, but I had trouble coming up with an actual reason I'd do that,
especially since the output from "aptitude search" is notably bad for
scripting.

> "?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.

It still is. I picked "?" because it is (a) suggestive of starting a
query word, (b) not ambiguous (all previous queries continue to have the
same meaning), and (c) it has a minimum of syntactic overhead. Something
like "~?name" is just obnoxious to type, although I could see adding it
as an alternative to see how it works. As you noted below, there's a
funny corner case when you mix the two styles of writing expressions, but
it doesn't affect backwards compatibility.

> 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.

"~ddpkg?name(dpkg)" means what it used to: match the regex
"dpkg?name(dpkg)" against the description field of packages. Terms
introduced by a tilde character still consume text up to the next
whitespace. This may be a bit surprising if you're used to the old syntax,
but it's predictable once you get the rule (I note, though, that the
documentation here needs to explicitly mention this). I feel this is an
acceptable level of annoyance to put up with for backwards-compatibility.

A more problematic example is "aptitude?installed", which is parsed as
a single regex. Again, though, just putting a space between the terms
makes everything work.

> > # 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?)

I didn't see a need to announce in NEWS, since it was backwards-compatible.
If you can find a case where it's not, that's a bug and needs to be
fixed, but I'm pretty confident from the implementation that it's not.
The new terms are only recognized in contexts where previous versions
would have tried to parse a regex and failed.

Daniel


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 04-16-2008, 05:22 AM
Daniel Burrows
 
Default Question about how "aptitude search" is used

On Tue, Apr 15, 2008 at 07:34:47PM +0200, "Kim N. Lesmer" <knl@bitflop.com> was heard to say:
> On Tue, 15 Apr 2008 07:13:30 -0700
> Daniel Burrows <dburrows@debian.org> wrote:
>
> Hi Daniel.
>
> > 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?
>
> I have always been annoyed with this exact problem, but I don't think
> the solution you think about implementing (doing like apt-cache) is the
> best way to go.

I'm not quite sure what you mean by "like apt-cache". I'm thinking of
something a bit more ambitious than just extending the search to
descriptions; e.g., Enrico Zini has done some interesting work in this
area that I'd like to incorporate or emulate.

> From FreeBSD:
> $ make search name=foo
>
> Aptitude:
> $ aptitude search foo

This would be like

$ aptitude search '~nfoo'

, right?

> Anyway, just a thought.

Users can already build up arbitrarily [0] complex queries if they know
the aptitude search language. The question is, what should
"aptitude search blah" do if the user hasn't provided any context about
what sort of a search to do? I don't think that erroring out is the
right thing to do; I think there should be a "default" search mode.

The only reason this comes up as an issue is that the old default
happens to have a very precise meaning that could conceivably have been
useful in scripts that ask for, e.g., "linux-image-2.6..*" instead of
"~nlinux-image-2.6..*". If the default had been "search names and
descriptions" to start with, I wouldn't be so concerned, because that's
clearly an interactive feature and not useful for scripts.

Daniel

[0] for some values of arbitrary; the aptitude search language has not
grown general, or even primitive, recursion operators, and I don't
have any reason to expect that it will. Anything that complicated
should probably be done in a real programming language (e.g.,
python with python-apt) anyway.


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 04-16-2008, 05:32 AM
Daniel Burrows
 
Default Question about how "aptitude search" is used

On Tue, Apr 15, 2008 at 05:55:58PM +0200, Jochen Schulz <ml@well-adjusted.de> was heard to say:
> Daniel Burrows:
> > 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.
>
> I like the full-text search idea, but I dislike the idea of approximate
> matches (without it being a different command or a parameter). It makes
> search results less predictable and hurts cases where your search terms
> yield many results anyway.

I think that depends on how approximate it is and how the results are
ranked. Obviously this will take a lot of tuning; my main point is that
I want to implement the most useful string-based search I can, and
that's not going to just search names. :-)

> Another aspect you should consider is speed. Aptitude is already quite
> slow and memory intensive. In my opinion, you should refrain from making
> it even more unsuitable for low-end devices than it already is. It's
> Debian's preferred package manager, after all.

Well, this won't impact anything other than "search", and it may
actually make things faster (I'll probably use an index on the package
cache, and I may even adjust the search interpreter to support some more
efficient modes of operation...)

Daniel


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 

Thread Tools




All times are GMT. The time now is 04:23 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org