Re: Question about how "aptitude search" is used

[Jörg-Volker Peetz]

Daniel Burrows wrote:



  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?



  I'm using aptitude mainly from the command line and sometimes its GUI but
so far not in any script. I like aptitude very much and prefer it over apt-get
or synaptic. Thank you very much, Daniel, for this very nice work.
I would appreciate another way to search for a package or tool
for a certain task. And for me its no annoyance to type an additional '~n'
to search for package names only. Normally I use constructions like

  aptitude -F "%M %p %25v %25V" search ~U
  aptitude purge ~c
  aptitude search ~o
  aptitude search '~i~D'

etc.
The only other packaging tool I use from time to time is dpkg to
- list files in an installed package
- search the package, a certain file belongs to
- unpack a .deb-file

--
Regards,
Jörg-Volker.


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Question about how "aptitude search" is used

[Daniel Burrows]

On Wed, Apr 16, 2008 at 08:02:21AM -0700, Andrew Sackville-West <[EMAIL 
PROTECTED]> was heard to say:
> On Tue, Apr 15, 2008 at 09:57:48PM -0700, Daniel Burrows wrote:
> > On Wed, Apr 16, 2008 at 12:38:46AM +0900, Osamu Aoki <[EMAIL PROTECTED]> 
> > was heard to say:
> ...
> 
> > > 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.
> > 
> 
> I've hesitated to respond for just this issue. I can't come up with
> any good reason to script an aptitude search. Mainly because, what the
> heck would you do with the output in a script? If you parse the output
> to find a particular package, that sort of implies that you already
> know what the package is and could just (install|hold|purge|whatever)
> it anyway without bothering to search for it. 

  I know that some people have *tried* to write scripts using aptitude
because they filed bugs about how lousy the output format is when used
for this purpose, although you can make it work with, e.g.,

aptitude search -F %p -w 1000 

  I don't know if anyone is using this sort of stuff in practice; from
the replies on this thread, I'd say probably not.

  Daniel


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Question about how "aptitude search" is used

[Florian Kulzer]

On Wed, Apr 16, 2008 at 08:02:21 -0700, Andrew Sackville-West wrote:
> On Tue, Apr 15, 2008 at 09:57:48PM -0700, Daniel Burrows wrote:
> > On Wed, Apr 16, 2008 at 12:38:46AM +0900, Osamu Aoki was heard to say:
> ...
> 
> > > 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.
> > 
> 
> I've hesitated to respond for just this issue. I can't come up with
> any good reason to script an aptitude search. Mainly because, what the
> heck would you do with the output in a script? If you parse the output
> to find a particular package, that sort of implies that you already
> know what the package is and could just (install|hold|purge|whatever)
> it anyway without bothering to search for it. 
> 
> I'm sure now I'll be called out and several will pipe up with myriad
> uses for aptitude search in a script... but that would be good as it's
> what you want.
> 
> IOW, IMO, I think you're pretty safe to move ahead. Probably a direct
> email to Florian Kuzler would suffice since he seems to be the master
> of arbitrarily complex aptitude search expressions

You are exaggerating greatly, but anyway, here are my two cents:

I don't use aptitude search commands in any scripts. If somebody does,
then I would expect those to be specialized queries for which people
will take care to specify all the operators (e.g. the "~i!~M" example
posted earlier). Everyone uses "apt-cache search -n" for simple searches
in package names anyway, because it is faster, right? A reason to prefer
aptitude in that case might be that someone wants to make their script
simpler by letting aptitude's output formatting options do some work
that would otherwise have to be done by piping the output to sed or awk.
My feeling is that such a person would be likely to specify "~n"
explicitly anyway in their scripts, even though it is currently not
necessary.

-- 
Regards,| http://users.icfo.es/Florian.Kulzer
  Florian   |


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Question about how "aptitude search" is used

[Andrew Sackville-West]

On Tue, Apr 15, 2008 at 09:57:48PM -0700, Daniel Burrows wrote:
> On Wed, Apr 16, 2008 at 12:38:46AM +0900, Osamu Aoki <[EMAIL PROTECTED]> was 
> heard to say:
...

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

I've hesitated to respond for just this issue. I can't come up with
any good reason to script an aptitude search. Mainly because, what the
heck would you do with the output in a script? If you parse the output
to find a particular package, that sort of implies that you already
know what the package is and could just (install|hold|purge|whatever)
it anyway without bothering to search for it. 

I'm sure now I'll be called out and several will pipe up with myriad
uses for aptitude search in a script... but that would be good as it's
what you want.

IOW, IMO, I think you're pretty safe to move ahead. Probably a direct
email to Florian Kuzler would suffice since he seems to be the master
of arbitrarily complex aptitude search expressions

A


signature.asc
Description: Digital signature

Re: Question about how "aptitude search" is used

[Daniel Burrows]

On Wed, Apr 16, 2008 at 10:45:22AM +0200, NN_il_Confusionario <[EMAIL 
PROTECTED]> was heard to say:
> On Tue, Apr 15, 2008 at 11:17:55PM -0700, Daniel Burrows wrote:
> >   Did aptitude work on this system in past Debian releases?
> 
> I use aptitude rarely and only for command-line tests (downloads,
> simulate installs,  compartation with the dependencies-resolving results
> with apt-get. _Never_ for installing).
> 
> But I can say that with the transitions woody ---> sarge ---> etch it has 
> become slower and slower (quite a lot solwer on my old hardware).

  I see.

> >  The only real
> > memory-hogging change in the program I can think of is the switch to
> > Unicode a few years ago;
> 
> Is it possible to locally recompile aptitude without such support, for
> testing pourposes?

  You could fetch a version from oldstable (0.2.whatever) and compile it.
It might take a little hacking since the C++ toolchain and apt have changed
since then.  You can't compile a current version without this support,
because the change touched more or less the whole program as well as
what later became cwidget; it's not just a matter of changing a few
lines to go back.

  If you only run from the command-line it's almost certainly not the
Unicode stuff that's biting you: aptitude hardly carries any strings at
all around in memory in that mode.

> > like the increase in the number of packages in the archive and changes in
> > the toolchain and standard library
> 
> I suspect that these three reasons are mostly responsable for sloweness
> (of aptitude and of other packages).

  Personally, I bet that much of the increase in memory usage can be
traced to the increase in the number of packages.  Can you maybe try
cutting down on the number of packages (e.g., by pointing sources.list
at oldstable temporarily) and see if that speeds things up?

> Is it possible to compile (for testing pourposes) the current aptitude
> with dietlibc or uclibc ? With older compilers ? (I recall that some
> time ago there were somewere in the net a recompilation of a not big but
> good and self-supporting part of woody with dietlibc, with only few
> patches to the source packages)

  I have no idea.

  Daniel


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Question about how "aptitude search" is used

[NN_il_Confusionario]

On Tue, Apr 15, 2008 at 11:17:55PM -0700, Daniel Burrows wrote:
>   Did aptitude work on this system in past Debian releases?

I use aptitude rarely and only for command-line tests (downloads,
simulate installs,  compartation with the dependencies-resolving results
with apt-get. _Never_ for installing).

But I can say that with the transitions woody ---> sarge ---> etch it has 
become slower and slower (quite a lot solwer on my old hardware).

>  The only real
> memory-hogging change in the program I can think of is the switch to
> Unicode a few years ago;

Is it possible to locally recompile aptitude without such support, for
testing pourposes?

> like the increase in the number of packages in the archive and changes in
> the toolchain and standard library

I suspect that these three reasons are mostly responsable for sloweness
(of aptitude and of other packages).

Is it possible to compile (for testing pourposes) the current aptitude
with dietlibc or uclibc ? With older compilers ? (I recall that some
time ago there were somewere in the net a recompilation of a not big but
good and self-supporting part of woody with dietlibc, with only few
patches to the source packages)

Are there somewere merory and speed comparation tests for the various
releases of GNU glibc and gcc ?

-- 
Chi usa software non libero avvelena anche te. Digli di smettere.
Informatica=arsenico: minime dosi in rari casi patologici, altrimenti letale.
Informatica=bomba: intelligente solo per gli stupidi che ci credono.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Question about how "aptitude search" is used

[Andrei Popescu]

On Tue, Apr 15, 2008 at 09:20:21PM -0400, Douglas A. Tutty wrote:
 
> 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)?

Do you have /tmp on tmpfs on that box too? (I know you have it on at 
least one other box). Because if aptitude is using some temporary files 
this would explain the swapping.

Regards,
Andrei
-- 
If you can't explain it simply, you don't understand it well enough.
(Albert Einstein)


signature.asc
Description: Digital signature

Re: Question about how "aptitude search" is used

[Andrei Popescu]

On Tue, Apr 15, 2008 at 10:32:40PM -0700, Daniel Burrows wrote:
 
> > 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. :-)

If you are going to output to console I think you will have to reverse 
the sort order, otherwise the most irrelevant match will be last and one 
would have to scroll up to see the more relevant ones. Or you could 
output directly to $PAGER (as 'git log' does).

Another idea that crossed my mind would be to restrict the number of 
results to something like 20 lines and add a note like: "These are the 
most relevant 20 results.  For the full list use --full and pipe to a 
pager"

Regards,
Andrei
-- 
If you can't explain it simply, you don't understand it well enough.
(Albert Einstein)


signature.asc
Description: Digital signature

Re: Question about how "aptitude search" is used

[Andrei Popescu]

On Tue, Apr 15, 2008 at 09:20:21PM -0400, Douglas A. Tutty wrote:
 
> 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.

That's what I do (inspired by Doug).

#!/bin/sh

[...]

aptitude search '~i!~M' > /home/amp/bak/pkg.list

I think it will be trivial to adapt to any changes.

Regards,
Andrei
-- 
If you can't explain it simply, you don't understand it well enough.
(Albert Einstein)


signature.asc
Description: Digital signature

Re: Question about how "aptitude search" is used

[Daniel Burrows]

On Tue, Apr 15, 2008 at 09:58:27AM -0500, "Mumia W.." <[EMAIL PROTECTED]> 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. ;-)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Question about how "aptitude search" is used

[Daniel Burrows]

On Tue, Apr 15, 2008 at 05:55:58PM +0200, Jochen Schulz <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Question about how "aptitude search" is used

[Daniel Burrows]

On Tue, Apr 15, 2008 at 09:20:21PM -0400, "Douglas A. Tutty" <[EMAIL 
PROTECTED]> 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


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Question about how "aptitude search" is used

[Daniel Burrows]

On Tue, Apr 15, 2008 at 07:34:47PM +0200, "Kim N. Lesmer" <[EMAIL PROTECTED]> 
was heard to say:
> On Tue, 15 Apr 2008 07:13:30 -0700
> Daniel Burrows <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Question about how "aptitude search" is used

[Daniel Burrows]

On Wed, Apr 16, 2008 at 12:38:46AM +0900, Osamu Aoki <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Question about how "aptitude search" is used

[Douglas A. Tutty]

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]

Re: Question about how "aptitude search" is used

[Kim N. Lesmer]

On Tue, 15 Apr 2008 07:13:30 -0700
Daniel Burrows <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] 
> with a subject of "unsubscribe". Trouble? Contact
> [EMAIL PROTECTED]
> 
> 


--
Med venlig hilsen/Best regards

Kim N. Lesmer
Programmer/Systems administrator

Web: www.bitflop.com
E-mail : [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Question about how "aptitude search" is used

[Jochen Schulz]

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:
 :)

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


signature.asc
Description: Digital signature

Re: Question about how "aptitude search" is used

[Osamu Aoki]

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]

Re: Question about how "aptitude search" is used

[Kamaraju S Kusumanchi]

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 [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Question about how "aptitude search" is used

[Mumia W..]

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 [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Question about how "aptitude search" is used

[Daniel Burrows]

  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 [EMAIL PROTECTED] 
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]