Michal Pryc wrote: > Brock, > I have read the proposal and reviewed the needs for the GUI. It looks > fine. I want to ask for two more things which will be necessary. > Great! Thanks for taking the time to look this over and get back to me. I'm glad it looks like it will satisfy your needs. > 1. Would it be possible to add authority to the search result, so from > which authority the search comes. I might be wrong and maybe this is > already the case. > Thanks for thinking of this, I'll look into making sure this information comes back as well. (bug 6413) > 2. The status of the package which is the result of the search. So > basically if the user is looking for: > pkg search /usr/bin/bash > How the user will know what packages are already installed on the system > from the search result. The per package result call to the api could do > the trick, but I am not sure about costs of such call. > This I'm less certain about the use of. If you do pkg search -l /usr/bin/bash then you'd only get hits if it was installed on your system. If this is a useful UI feature, I can explore it more. For the GUI, since there's already a source of information about package status else where, if it's needed for a UI interface, I think that's a better source of that information. If it's needed for the CLI, I'll think about it. With variants and facets, it becomes a more difficult question to answer without running the search again locally anyway since a package might be installed, but the action in that package which matched the remote search might not be installed b/c of a variant or facet.
Brock > best > Michal > > Brock Pytlik wrote: > >> Michael Schuster wrote: >> >>> On 01/30/09 13:05, Brock Pytlik wrote: >>> >>>> Michael Schuster wrote: >>>> >>>>> 1) I see you mixing short and long options. Is that necessary? >>>>> >>>> There are a limited number of letters, and a lot of pkg subcommands. >>>> To attempt to reduce conflicts, I used long options for rare options. >>>> Mostly, I closed my eyes and picked the first letter/string which >>>> came to mind, I didn't put much thought into the option format at this. >>>> >>>>> 2) if you need an option to limit the number of results, I see -n as >>>>> the more obvious than -z. >>>>> >>>> -n has meanings in other contexts. I don't care what letter is >>>> chosen, I chose -z for size >>>> >>> do you mean "pkg search -n" is already taken, or that "pkg -n ..." is >>> taken? >>> >> I mean pkg install -n, pkg uninstall -n, etc already have defined >> meanings, and fairly important ones. I'm hesitant to create competing >> associations in the users mind for that particular option. >> >>>>> 3) the syntax for "find everything in /usr/bin" seems rather >>>>> complex. From a previous discussion on this subject, shouldn't "pkg >>>>> search /usr/bin" be able to "do the right thing" (since /usr/bin >>>>> traditionally contains only files ... ;-) >>>>> >>>> Well, pkg search /usr/bin/* "does the right thing". >>>> >>> are you considering shell globbing effects here, or just using >>> unquoted notation for simplicity of this exchange? >>> >> Using the unquoted notation for simplicity. I can't really control the >> shell globbing effects, and I think that defining our own '*' is >> probably not the way to go. If there's an alternative, I'd love to hear it. >> >>>>> 4) the expression syntax for and/or'ing stuff is ... ahem ... >>>>> different from any other Solaris utility I know. Other precent to >>>>> look at: find(1), snoop(1M), eg. >>>>> >>>> Well, from what I saw from glancing at the find man page, I didn't >>>> see provisions for AND or OR, I only saw an implicit AND. >>>> >>> expression -o expression. (including grouping with "()" - all very >>> messy with shell escapes, etc.) >>> >>> I'm not saying it's ideal, but many unix people know it - it has been >>> around for some time, after all ;-) >>> >> Unless I hear a large outcry, I don't think I'll be offering the -o >> expression to mean "or". Especially not considering that -o may be an >> option (a la pkg contents) to allow fine grained control over the output >> categories. I think googlisms are a more reasonable style to take hints >> from, especially given our goal of targeting a broader class of users. >> Like I said, if there's a large outcry, I'll reconsider. >> >> Brock >> _______________________________________________ >> pkg-discuss mailing list >> [email protected] >> http://mail.opensolaris.org/mailman/listinfo/pkg-discuss >> > > _______________________________________________ > pkg-discuss mailing list > [email protected] > http://mail.opensolaris.org/mailman/listinfo/pkg-discuss > _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
