On 09/21/10 05:44 PM, Danek Duvall wrote:
Shawn Walker wrote:
http://cr.opensolaris.org/~swalker/pkg-2775/
The way that reinstall seems to be implemented, it smells a lot like
"upgrade". That is, there are no restrictions against using it to uprev
the version of a package, and it should be easy to do by simply saying "pkg
reinstall foo". Perhaps that's intentional. So what we have (eventually)
is:
pkg install upgrades a package or adds it to the system
pkg reinstall upgrades or downgrades a package, but will not add it
pkg upgrade upgrades a package, but will neither downgrade nor add
Seems like the overlap might be unnecessary. Should we have "upgrade" and
"downgrade", each of which enforces their name? Should we have a single
command that upgrades by default to the latest, but can take you to any
arbitrary revision if requested? Should a combined upgrade/downgrade
command require a flag to downgrade you? A future RFE might be to take you
to the most recently previously installed version of a package; how might
that fit in?
Without designing it, I'm unceratin how an RFE to take the user to last
installed version might be implemented. So I'm going to punt on that
for now.
However, as per our earlier off-line discussion, I've chosen to let my
'reinstall' work be subsumed into the 'update' subcommand that's been
discussed previously (RFE 3436).
...
pkg.1.txt:
- I think rather than splitting install and uninstall out and addint
reinstall as another, mostly similar, subcommand, we might want to keep
them together, particularly since we're also considering the "update"
subcommand, which is going to be again mostly similar.
Perhaps have the full text for install and for reinstall, after
explaining what it does and why you'd use it, just refer the reader to
the section on install for an explanation for all options and
arguments. Ditto for uninstall, noting which of the options aren't
valid.
I've completely reworked this to attempt to duplicate as little text as
possible and re-worded some of the text.
...
api.py:
- line 423: noexecute really determines only the history?
Technically, it also controls whether you *can* execute the resulting
plan, but it's a bit of a misnomer since just planning an operation
doesn't execute it regardless of whether you specify 'noexecute'.
However, I've reworded this text here and updated the docstrings for all
the other functions; *sigh*.
- line 424: The referent for "It" is ambiguous.
Fixed here and other places; again same text we used for all the other
functions.
I'll send out an updated webrev later this afternoon.
Thanks,
-Shawn
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
