On Mon, 17 Oct 2005, Garrick Staples wrote:
> On Tue, Oct 18, 2005 at 01:28:28PM +0800, Jeff Pitman alleged:
>> On Tuesday 18 October 2005 13:15, seth vidal wrote:
>>> it's mostly b/c it is doing a regex of .*userstring.*
>>
>> Are we stuck with being legacy compat with multiple representations of
>> packageSack? Because this could be re-tooled to use a SQL "like" query
>> into a carefully keyed sqlite database.
>>
>> Also, we could learn lessons from rpmfind.net and rpm.pbone.net about
>> how the search should be setup. For example, if they want to look for a
>> file, then provide full path. Code then keys off of "/". Then, a plain
>> "mt" only looks in package names. If user doesn't know if "mt" is
>> in /usr/bin or /usr/sbin, then burden is placed on the user to
>> enumerate the possibilities.
Yeah, and the reason that I was doing this in the first place is that I
couldn't FIND the mt binary in the first few places I looked and the mt
package is named "mt-sc" or the like (yeah, sure, first thing I thought
of). Eventually I found it, just not with yum provides. It's just that
no, yum shouldn't crash on ANY user string and yes, there are search
algorithms that wouldn't crash. The one being used, for example, as
long as it uniques the results per package. Finding occurrences of mt
per package is a linear problem (in the number of packages) solved by
egrep and friends. egrep and find manage it linear in time and nearly
flat in storage. The only trick is appropriately saving and uniq'ing
the intermediate hits so that you don't show any given package more than
once and so that you don't search the same line of metadata more than
once (per requirement of the regexp).
rgb
>
> Then you search on "bin/mt". Likewise, "lib/libmt", etc.
>
>
>> Searching files, package names, etc. etc., in one swoop can be a
>> gargantuan undertaking.
>
> Just to throw this out there, I've always liked how urpmi handles
> searching. You have 'urpmq' which searches in package names and
> provides, and 'urpmf' for filenames.
>
> I'd love it if yum had two different arguments for searching
> names/provides and filenames. Maybe this is a job for yum-utils?
>
>
--
Robert G. Brown http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567 Fax: 919-660-2525 email:rgb@xxxxxxxxxxxx
