Brock Pytlik wrote:
Since this fixes the -p option to do what it should've always done, it
made sense to me to change the default behavior to be to return packages.
I assert, with admitedly no data to back this up, that the only bit of
information that most users care about most of the time is "which package
do I install to get X." The change in default behavior makes search more
useful for the common case I believe.
They already get that information, and more, with the current default.
Perhaps when the search results are based on paths, this is not an issue,
but certainly when searching on metadata, you can get some very odd-looking
results with -p. For instance, if I search for "smf", then with -p, I get
PACKAGE PUBLISHER
pkg:/service/gnome/[email protected]
opensolaris.org
pkg:/system/kernel/dynamic-reconfiguration/[email protected]
opensolaris.org
pkg:/system/management/[email protected]
opensolaris.org
none of which particularly make sense to me. Perhaps I can tell that none
of these deliver SMF, but why on earth did I get these back. With -a, the
result is more comprehensible (modulo the long values):
INDEX ACTION VALUE
PACKAGE
description set desktop-cache is a set of SMF services used to
update the various GNOME desktop caches.
pkg:/service/gnome/[email protected]
pkg.description set desktop-cache is a set of SMF services used to
update the various GNOME desktop caches.
pkg:/service/gnome/[email protected]
pkg.description set Dynamic Reconfiguration Modules for i86pc required
to support hotplug on i86pc based systems. Includes the ACPI Hotplug Daemon,
SMF manifests/methods and drivers for hotplug operations.
pkg:/system/kernel/dynamic-reconfiguration/[email protected]
pkg.summary set desktop-cache is a set of SMF services used to
update the various GNOME desktop caches.
pkg:/service/gnome/[email protected]
basename dir etc/webmin/smf
pkg:/system/management/[email protected]
basename dir usr/sfw/lib/webmin/caldera/smf
pkg:/system/management/[email protected]
basename dir usr/sfw/lib/webmin/smf
pkg:/system/management/[email protected]
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.
While it's safe to make the switch now, because we have plenty of time to
switch it back if people don't like it, it'd be nice to see some data on
what people other than you or me actually would expect. I can live with it
either way -- I'll just learn to use -a, just like I've learned to use -l
-- but if the option is one most people will end up using, then perhaps it
should just stay the way it is.
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).
I went back and read the code review comments at the time and found one
suggestion[1][3] for making returning packages be the default behavior,
as well as some explanations for why that wasn't a good idea at the
time(the reply to [1] and [2]). [2] doesn't apply any more as we've
dropped support for v0 search.
Ideas for getting data about user preferences:
Ask on pkg-discuss (or indiana-discuss or opensolaris-discuss).
Put a poll up online (opensolaris.org supports this?)
My impression from conversations with "people" was that packages should
be the default, but I also admit I have no concrete examples I can draw
from nor could I find much in the way of comments from actual users (as
opposed to people on the team) with opinions on whether -a or -p should
be the default.
Thanks,
Brock
[1] http://mail.opensolaris.org/pipermail/pkg-discuss/2009-March/011495.html
[2] http://mail.opensolaris.org/pipermail/pkg-discuss/2009-March/011525.html
[3] http://mail.opensolaris.org/pipermail/pkg-discuss/2009-March/011529.html
Danek
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
