On 06/10/11 13:53, [email protected] wrote:
On Fri, Jun 10, 2011 at 12:13:11AM -0700, Brock Pytlik wrote:
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.
Not that you care what I think, but this seems inconsisent with the way
that most UNIX command line utilities work. Generally, if a command
returns no output, the user assumes that the operation has succeeded. I
would either return no output if the command succeeds, and print the
packages that it failed to unfreeze, or print output for both the
success and failure cases. (My own preference is for the former).
Also, what's the return code from pkg(1) if the unfreeze doesn't match
any packages? If you return 0, you're saying this operation succeeded,
even though nothing was matched, which would be hard to script against.
-j
It returns 4 if no packages were unfrozen. I'm fine with including some
message like "no frozen packages matched the given patterns." but that
opens up the question of whether that means that if some patterns
matched, and some didn't, we should return an error code of 1, and not
update the state of any packages (like freeze and other commands).
Fundamentally, I think it depends on whether you view unfreeze (and
freeze though that's less of an issue) as instructions of state
transitions to make or a declaration of a desired state. If it's the
former, then errors and messages should be reported. If it's the later,
then 'pkg unfreeze foo' when foo isn't frozen is just fine because it's
saying "I want the state where foo isn't frozen", which is the current
state.
The advantage of the declaration of state approach is that it's easier
to script against (I think). The advantage of the instructions of state
transitions is that it helps catch user typos. I chose the declaration
of state approach because I thought the ease of scripting was
preferable, but I'm happy to switch to the state transition approach if
we decide that's a better UI.
Thanks for taking a look!
Brock
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
