Brock Pytlik wrote:
I'm not sure this is the best example (because I'm not sure what you were
hoping to get out of searching smf but the info I'd hope for, like what
package installs smf, or smf services, isn't really present in either set
of results) but I also don't think quibbling about examples is fruitful.
I was playing the part of the naive user who wanted to find out what
package installed SMF (because it's one of Solaris' coolest features). Of
course, I don't know that no single package does that, so all I get back is
bogus results. With -a, I at least know why each package was shown to me,
even if I'm still lost as to what package delivers SMF.
I'm happy to gather the data, but I've no idea how go about it. Because
-a (effectively) was the default, the numbers are obviously skewed
heavily in one direction. What I feel reasonably safe in saying is that
in queries with more than one term in them, almost no one actually wanted
the effect of using multiple bare terms in a -a query. Now, maybe the
number of multiterm queries is so tiny that it's meaningless (and that's
data we can get).
It might be a useful datapoint, though if people never use it because it's
too hard to use correctly, the data might not be all *that* useful.
Yeah, it might at least get us the number of queries/people who at least
attempted a multi-term query before giving up in confusion.
I hardly ever use multiple term searches, so I tried a couple. I tried to
find a package that contained both "smf" and "/lib/svc/method". Being
confused by the use of "<>", I tried a bunch of differeht things:
Right, I agree "<>" is confusing. That's one reason I was suggesting a
move to -p as the default. It puts the <>'s in "the right place" for
most users.
pkg search smf /lib/svc/method
pkg search "smf /lib/svc/method"
pkg search "<smf lib/svc/method>"
pkg search "<smf>""</lib/svc/method>"
When I ran these as local searches, I got no output for the first three
and this for the last one:
PACKAGE PUBLISHER
pkg:/service/gnome/[email protected]
where the quotes are shell-parsed.
I (as a slightly less naive user than before) still would have expected for
at least one of those queries to return at least the desktop-cache package
Which is why I'm suggesting that -p is the right default.
which delivers a set action with the word "smf" in it and a directory
action with the path /lib/svc/method.
The first three each returned no results, and the last resulted in a 502
Bad Gateway, which, IIRC, is what happens when Apache times out its
connection to the back-end depot. Is that going to be the new behavior of
the first command above?
I don't know why you got a 502 error, but that's a bug/problem w/ the
depot I haven't seen before. I'll look into it when I have a chance. It
should have returned (roughly) the same info as the local search. The
first two posed were identical searches. The third was identical to the
old behavior of pkg search -p smf /lib/svc/method. The fourth is what
the new behavior of pkg search -p smf /lib/svc/method would be.
While I'm open to -p by default, it's certainly less useful to me, and I'm
curious to see some actual reasons why people would prefer it, other than
unsupported statements from you and Shawn expressing your belief that this
is what people expect and/or would want. I know collecting data on this is
hard; I'd be happy even with some anecdotal evidence from people not
directly on the pkg(5) team.
I agree, that's why I threw out the idea of posing the question on
discussion lists/starting a poll somewhere. By the same token, I'd like
to see more than one person stating they'd like to keep -a as the default.
I'm also fine with changing the bug synopsis to be "-p doesn't handle
multi-term queries properly" and leave the default where it is. Search
doesn't seem to as important as some of the other things we might spend
time on, so things that involve gathering lots of data or running user
studies (both of which imply a fair bit of time commitment) probably
aren't going to get done any time soon.
Danek
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
