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-16-2008, 05:50 AM
Daniel Burrows
 
Default 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. ;-)


--
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, 06:17 AM
Daniel Burrows
 
Default Question about how "aptitude search" is used

On Tue, Apr 15, 2008 at 09:20:21PM -0400, "Douglas A. Tutty" <dtutty@porchlight.ca> 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 debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 04-16-2008, 06:47 AM
Andrei Popescu
 
Default Question about how "aptitude search" is used

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)
 
Old 04-16-2008, 06:57 AM
Andrei Popescu
 
Default Question about how "aptitude search" is used

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)
 
Old 04-16-2008, 07:02 AM
Andrei Popescu
 
Default Question about how "aptitude search" is used

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)
 
Old 04-16-2008, 08:45 AM
NN_il_Confusionario
 
Default Question about how "aptitude search" is used

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

On Wed, Apr 16, 2008 at 10:45:22AM +0200, NN_il_Confusionario <pinkof.pallus@tiscalinet.it> 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 debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 04-16-2008, 03:02 PM
Andrew Sackville-West
 
Default Question about how "aptitude search" is used

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 <osamu@debian.org> 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
 
Old 04-16-2008, 07:39 PM
Florian Kulzer
 
Default Question about how "aptitude search" is used

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

On Wed, Apr 16, 2008 at 08:02:21AM -0700, Andrew Sackville-West <andrew@farwestbilliards.com> 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 <osamu@debian.org> 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 <term>

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 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 08:32 PM.

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