This is looking good, Shawn. I have some mostly minor comments.
On 1/12/12 4:28 PM, Shawn Walker wrote:
* version fields now have a ':' delimiter for readability
* if a pkg provides pkg.human-version, it is shown first with the
actual version in parentheses
* version shown no longer include build_release (since it will likely
always be ",5.11")
Hm, always? Or do we expect to update this when we release 5.12?
Perhaps it should only be printed if they differ?
END-USER EXAMPLES
=================
# pkg update -n
...
PACKAGE CHANGE SUMMARY
solaris
entire
I know you said you're not convinced yet, but this is a bit opaque to
me, especially as we get to the subsequent examples in END-USER. I'd
really wonder about combining them on the same line with some labeling.
Installed: FCS Build 2 (0.5.11-0.175.0.0.0.2.0)
Proposed: SRU 1 Build 4 (0.5.11-0.175.0.1.0.4.0)
Latest: SRU 2 Build 3 (0.5.11-0.175.0.2.0.3.0)
...
Shows an update from release to a newer SRU, but not the latest which
has been blocked by a pkg freeze, unbundled product, or some other
package. 'entire' is shown because it is the top-level of the
install-hold chain (in this case, 'core-os'). The other incorporations
are hidden even though they are changing because they are incorporated
by the package delivering the 'core-os' install hold. The Latest version
is only shown if the proposed version is older.
If we aren't going to do an explicit message that proposed != latest, I
think it might be clearer to the user to re-order as Installed, Latest,
Proposed. I also began to wonder if proposed == latest if you print as
Proposed (Latest): ...
# pkg update -n
...
PACKAGE CHANGE SUMMARY
solaris
entire
Installed: FCS Build 2 (0.5.11,5.11-0.175.0.0.0.2.0)
Latest: SRU 2 Build 3 (0.5.11,5.11-0.175.0.2.0.3.0)
No updates possible. If updates were expected, execute the command again
and specify each package listed above with the desired version for more
information.
...
Shows a case where newer packages are available, but cannot be updated
to because they have been blocked by a pkg freeze, unbundled product, or
some other package. 'entire' is shown because it is the top-level of the
install-hold chain (in this case, 'core-os') of the installed
incorporations. (This failure to update is not considered an error
because it is impossible to determine whether the result is intentional
without explicit user input.)
Also note that it says 'possible' instead of 'available' and that pkg(1)
would exit with code 6 in this case (a new code used to indicate that no
changes were made but potential updates are available). Currently,
pkg(1) would only show the message 'No updates available.' and then exit
with code 4.
I'm a little confused here. It isn't an error but it'll return with
exit code 6?
DEVELOPER EXAMPLES
==================
These examples assume 'entire' has been removed:
# pkg update -n
...
PACKAGE CHANGE SUMMARY
on-nightly
consolidation/osnet/osnet-incorporation
Installed: Update 1 Build 6 Nightly 18318
(0.5.11-0.175.1.0.0.6.18318)
Proposed: Update 1 Build 6 Nightly 18339
(0.5.11-0.175.1.0.0.6.18339)
pkg5-nightly
consolidation/ips/ips-incorporation
Installed: 0.5.11-0.175.1.0.0.0.2603:20111220T130654Z
Proposed: 0.5.11-0.175.1.0.0.0.2603:20111222T130712Z
...
Shows an update from a previous nightly to a newer one.
'osnet-incorporation' is shown because it is the top-level of the
install-hold chain (in this case, 'core-os.os-net') and
'ips-incorporation' because it is also at the top-level ('core-os.ips').
No other incorporations are changing so they are not listed.
Might I suggest printing these in reverse publisher order, if you aren't
already? That is, show the first publisher last (under the theory the
first publisher is most important)?
# pkg update -n
...
PACKAGE CHANGE SUMMARY
on-nightly
consolidation/osnet/osnet-incorporation
Installed: Update 1 Build 6 Nightly 18318
(0.5.11-0.175.1.0.0.6.18318)
Proposed: Update 1 Build 6 Nightly 18320
(0.5.11-0.175.1.0.0.6.18320)
Latest: Update 1 Build 6 Nightly 18339
(0.5.11-0.175.1.0.0.6.18339)
pkg5-nightly
consolidation/ips/ips-incorporation
Installed: 0.5.11-0.175.1.0.0.0.2603:20111220T130654Z
Proposed: 0.5.11-0.175.1.0.0.0.2603:20111221T130623Z
Latest: 0.5.11-0.175.1.0.0.0.2603:20111222T130712Z
...
I began wondering here if it's worth aligning the versions when
possible. It's trickier when there is a human-readable version tag, but
certainly when there is none, it'd be easier for the eye to look for
differences.
(I realize once we get to a difference between version .9. and .10. it's
a little bit of a loss, but I think usually this would be helpful.)
liane
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
