Brock Pytlik wrote:
Michal Pryc wrote:
Brock,
Thanks. I see that this is not a part of manifest data, so it's
unfortunately not supported :(
I wonder then if it make sense to perform search for the description
and then local query to get package name then? Or maybe allow to
search against description or name and at some point the fmri will be
available in the repositores??
I think we're going to have to fix this at some point to allow manifest
signing (assuming we don't decide the right answer is to take it out of
the client side manifests), I just don't know what schedule that's
happening on. I also think there's some disagreement on what the right
solution is.
It's possible that this could still make the release on the server since
bug fixes can happen for a little bit yet, but in case there's any
confusion, I'm not making any promises.
Honestly, I've always been confused as to why you want to restrict a
search to only package name and description. If I'm looking for a
library or program named foo that happens to be packaged inside a
package named bar, I'd think I'd want a search for that to work. I'm
open to understanding why you want the restriction on search though.
This was by design for simple remote search. Later we will probably want
to search for files and other metadata, but we need to think how to
represent the search results on the GUI side (maybe switch the details
panel to files and highlight the found string??). At that point we
probably will want some more search parameters etc... which was not
planned for this rev.
best
Michal
Brock
best
Michal
Brock Pytlik wrote:
Michal Pryc wrote:
Brock,
Does it mean that we are unable to perform remote search for name
and description of the packages?
Another question is how to perform search with OR statement from the
command line.
I want to search for name OR description of any package in any
repository/publisher, how such statement would look like?
If we supported remote search on a package name, it'd look like this:
pkg search ':attribute:fmri:foo OR :attribute:description:foo'
OR should work as expected, if it's not doing what you anticipate,
please let me know.
Brock
best
Michal Pryc
Brock Pytlik wrote:
Padraig O'Briain wrote:
On 03/05/09 21:21, Brock Pytlik wrote:
That particular search is hitting bugs 7121/7045. The manifest on
the server does not have a set name=fmri value=<pkg name> action,
so there's nothing to index, hence, there's nothing
Is there any estimate of when these bugs will be fixed?
Not at the moment, no. It'll have to get fixed for manifest signing
to work, if I've understood bart, but other than that, I don't know
that anyone has plans to work on it soon.
Brock
Padraig
to return. What kind of specification are you looking for? The
most accurate way is to examine the generate indicies functions
in the action code. That's what specifies what's indexed for each
action type.
Brock
Padraig O'Briain wrote:
Is there a specification somewhere of what the values returned
by remote_search mean?
pkg search -s http://ipkg.sfbay:40123 '<SUNWipkg:attribute:fmri:>'
does not return anything.
Padraig
On 03/05/09 12:08, Brock Pytlik wrote:
Padraig:
As I've said, this is code that is/was still in very active
development. You're seeing various bits of debugging output.
The searches you've tried before should be succeeding better
now, several performance fixes went in so that they at least
complete before a timeout happens.
Those debugging lines should be removed in this new webrev.
http://cr.opensolaris.org/~bpytlik/prelim_search_v1_v5/
Everyone:
I believe this webrev to now be totally functional modulo one
intermittently failing test case (t_pkg_search.test_4048_2 if
you're scoring at home) which I'll look into tomorrow. I've
done a first pass at cleaning up the formatting and removing
commented lines, so it's the first one I feel comfortable
asking for substantial feedback on. I know there's still a fair
bit of dead code to be removed, and much doc
strings/documentation change to be made and a fair amount of
performance to try and find on the server. That said if this
code was bug free (I'll wait for the laughter to die down) I
think from a feature/performance point of view, it's ready,
though it's quite possible some new combination of queries will
prove that not to be the case.
Shawn:
I'd like your advice if you have the time on how to handle the
combination of versioned_url open, 404 errors, and retries.
Right now, I use 404 if the version isn't supported, and 410 if
the search found nothing (so that versioned_url knows not to
retry). If I've understood everything correctly, now that we're
at CP3.1.1, we can use a status message to distinguish those
two cases (like we did a long time ago). If so, can you point
me to an example of how to set it?
Thanks,
Brock
Padraig O'Briain wrote:
Brock,
When I started packagemanager I got 431759 lines of output.
I have attached the first and last ten lines.
Padraig
On 03/04/09 21:05, Brock Pytlik wrote:
Padraig O'Briain wrote:
As you can see search for <info.classification:games>
worked. However search for <SUNWipkg:attribute:fmri:> did
not. It also seemed to crash the server which was
unavailable for some time before becoming available again.
Padraig
bash-3.2$ pkg search -s http://ipkg.sfbay:40123
'<info.classification:games>'
PACKAGE
pkg:/[email protected]
pkg:/[email protected]
pkg:/[email protected]
pkg:/[email protected]
pkg:/[email protected]
pkg:/[email protected]
pkg:/[email protected]
pkg:/[email protected]
pkg:/[email protected]
pkg:/[email protected]
pkg:/[email protected]
pkg:/[email protected]
pkg:/[email protected]
pkg:/[email protected]
pkg:/[email protected]
pkg:/[email protected]
Good
bash-3.2$ pkg search -s http://ipkg.sfbay:40123
'<SUNWipkg:attribute:fmri:>'
pkg: Some servers failed to respond appropriately:
http://ipkg.sfbay:40123: timeout
I'll think about how to fix this.
bash-3.2$ pkg search -s http://ipkg.sfbay:40123
'<info.classification:games>'
pkg: Some servers failed to respond appropriately:
http://ipkg.sfbay:40123: timeout
When I ran this again, it worked, though it took longer b/c
the server was still under heavy IO load from the first search.
Brock
On 03/04/09 11:54, Brock Pytlik wrote:
http://cr.opensolaris.org/~bpytlik/prelim_search_v1_v4/
Fixes pkgdefs, boolean search, other various bugs. Adds a
number of tests. A depot running under this version
shouldn't die or have memory blow up with searches of '*'
or other fun combinations. Feel free to try AND and OR in
your queries as well. While I'm sure there are bugs waiting
to be found, I'm not aware of any potential pitfalls at the
moment. In other words, my hope is to clean up the files
and have a real webrev out for review later today.
The depot on ipkg:40123 has been updated to these latest
bits (and also has had the content root set so pointing at
it with a web browser should work now though the search in
the BUI hasn't been updated to send search_v1 searches.)
Please let me know if there are either bugs you encounter
or things you don't like.
Thanks,
Brock
Brock Pytlik wrote:
It appears a change needs to be made to the pkgdefs/*.
I'll talk to some people and find out whether it's
expected I need to modify these files or not.
Brock
[snip]
_______________________________________________
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
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
