Re: Question about how aptitude search is used
Daniel Burrows wrote: snip 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~Dpattern' 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
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
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
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
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
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
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
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
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
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
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
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 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 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 [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 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 signature.asc Description: Digital signature
Re: Question about how aptitude search is used
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
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
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
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]
