On 07/14/11 01:12 PM, Shawn Walker wrote:
On 07/13/11 19:40, Brock Pytlik wrote:
Webrev:
https://cr.opensolaris.org/action/browse/pkg/bpytlik/17801-v1
Bug:
17801 contents -r should use same matching rules as install
I'm suspicious that the better fix for this might be to create a new api
function, something like get_pkg_names, and switch contents, fix, and
verify over to it, but I'm not sure that would be better in the long
haul.
It looks like you indirectly, partially resolved this one:
17802 contents -r should filter results based on image variants by
default
So there are a few shortcomings I see with the approach taken here:
* need a -f option like pkg list and search have, because contents
-r used to match SPARC packages on x86 systems and now won't return
results (that's bad; Comay and others use this a lot); this also
is technically a flag day or at least a heads up since it will
filter on variant by default
Well, that behavior does match exactly what the bug called for, but I
agree it's less than ideal. I'll see what can be done about adding a -f
option (of course, then the question becomes which filters -f turns off
... variants, incorporations, newest, etc...). So if a -f option needs
to be added, I'd like the answer to that question.
* the downsides of not using get_pkg_list() to generate the data are:
-- no iterative return of results
I don't see this as a huge downside for this use case.
-- no incorporation filtering (or obsolete/rename handling)
I could perhaps deal w/ the incorporation filtering by intersecting the
results from get_pkg_list w/ the results from the current results. I'm
not sure what kind of obsolete or rename handling you'd expect, but it'd
seem to me that if I asked for the contents of a renamed package, i'd
get the contents which included the renaming action, not the contents of
the package it had been renamed to.
I'd also note that the same changes you made for contents could be
made for info, but inside pkg.client.api:
17803 info -r should filter results based on image variants by default
17804 info -r should use same matching rules as install
All of the above bugs are assigned to me, but you can take them.
Or if you have an idea of a solution which handles the issues you raised
above, you can take this one.
src/tests/cli/t_pkg_contents.py:
So the last time I talked with Danek, I believe he indicated that
it would be preferable to get away from adding tests named after or
only for specific bugs, and to instead integrate the additional
correctness checks with existing tests or name them after the
behaving being tested as we would normally during initial
implementation. You can still have the bug numbers in comments
though; ask him about this.
These tests can't be combined with earlier ones since they need a many
repo setup.
lines 223-226: this doesn't appear to be used
lines 262-263: I don't see why publisher ranking would cause a simple
stem match to fail.
Perhaps the comment wasn't clear. What I tried to indicate was, "if the
test2 publisher was ranked first, this would succeed because the
publisher ranking filter would mean that only a single package matched
the stem. Since it's not, then a multiple match still happens."
lines 268-269: The comments seem to indicate that this will verify
that it only matched the newest version, but I see nothing in the
test to look in the output to see if the pkg.fmri matched expected.
Thanks, I'd lost that code as I went back and forth on the tests.
Brock
-Shawn
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
