On 06/16/11 11:23, Shawn Walker wrote:
On 06/10/11 00:13, Brock Pytlik wrote:
Webrev:
http://cr.opensolaris.org/~bpytlik/ips-18441-v1/
Bug:
18441 pkg needs a freeze mechanism
These changes provide the freeze mechanism I outlined previously. The
biggest changes I know of from the original use cases I sent out are
that:
1) If pkg unfreeze <blah> doesn't match any frozen packages, no error is
reported. I decided that seems reasonable since pkg unfreeze details
each package that was unfrozen, so no output means no packages were
unfrozen.
2) Publishers can be part of the patterns used for matching, but a
package is only frozen to a version, not to a publisher.
I think that covers the major changes.
src/client.py:
line 2159: docstring indicates this only sets freezes, but it also
displays them
I'll fix this once we decide what we're doing below.
lines 2199-2200: Having unfreeze display packages as well as freeze
is inconsistent with the paradigm we use for other commands. I'd
rather not have both of these commands be capable of displaying the
list of frozen packages. This is also not documented in the man
page.
It exactly mirrors the paradigm that avoid uses. Since that looked like
freeze's closest cousin, I used that as my reference.
line 5366: what, not "thaw" instead? (joking)
:)
src/man/pkg.1.txt:
lines 640-641: s/end up/be updated to/ ?
sure
lines 648-649: suggest:
With -n, perform a trial run of the operation, displaying the
list of packages that would be affected by the freeze without
freezing any packages.
Sure
At least, I think it should display the list of packages it would
constrain. (And it seems that it does currently.)
Yep
You may also want to mention that publisher information in the FMRI
will be ignored. (That is, you can't place publisher-specific
freezes, although that might be a nice future RFE to allow
per-package stickiness.)
Well, it's not ignored, it's used during the matching, that's why I
didn't complain if the user put a publisher there.
line 653: s/. Any/; any/
ok
lines 655-656: Suggest:
With -n, perform a trial run of the operation, displaying the
list of packages that will be unfrozen without unfreezing any
packages.
Like above, I'd hope it would display the list of what would be
affected. (And it seems that it does currently.)
sure
No examples?
I'll add some.
src/modules/client/api.py:
line 615: Can you rename 'message' to 'comment' or 'reason' to be a
bit more descriptive? And if so, change it everywhere else?
'reason' would at least be consistent with the man page.
I guess
lines 617-619: copy paste? (still refers to avoid/unavoid)
oops, thanks
src/modules/client/api_errors.py:
line 2740: s/were/are/ ?
sure
line 2754: s/don't contain/contain no/ (to avoid the double don't)
sure
src/modules/client/image.py:
line 3725: s/users/user's/
mhmm
lines 4061, 4071: s/pacakges/packages/
thanks
src/modules/client/imageplan.py:
lines 2323: The variable names are a bit hard to grok, can you rename:
'not_match_ok' -> 'raise_unmatched' and 'not_inst_ok' to
'raise_not_installed'? That would also have the benefit of getting
rid of the double negative expressions on lines 2454-2455 (e.g.
not not_match_ok).
gee, that was what I had originally, then changed to match the naming
scheme that Ed used in his recent putback.
line 2515: same concern as that on 2323 for variable name, thanks
line 3003: brief docstring appreciated
sure
line 3050: s/==/ == /
k
line 3060: 4-space continuation indent
k
src/modules/client/pkg_solver.py:
lines 369-371, 663-664: suggest (mainly to get rid of freeze's
reason):
This version is excluded by freeze {0}. The reason for the freeze is:
{1}
sure
src/tests/cli/t_pkg_freeze.py:
line 38: shouldn't this be True? (image are destroyed and created
every time anyway I thought...)
Doesn't appear to be the case. Turning on persistent setup immediately
caused all but the first test to fail. Setting this to true then moving
the image creation into each test, instead of the setUp method saved 3
seconds.
Missing a test to verify bad FMRI input doesn't cause traceback.
k
Thanks for taking a look.
Brock
-Shawn
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
