On 01/24/12 16:48, Liane Praza wrote:
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?
Actually, yes, the intent is to show it only if different. I failed to
update this particular bit of text with that to make it explicit.
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.
Hmm. I was trying to avoid showing the same publisher multiple times if
multiple incorporations are shown to be updating; this is similar to the
current output you see from 'pkg update -nv'.
I'm open to suggestions here as I can't seem to find a display format
that is easy on the eye. Some possibilities I can think of quickly are
(note I purposefully omitted version text for layout clarity below):
Format 1 Examples
=================
//solaris/
entire
Installed:
Proposed:
Latest:
//on-nightly/
consolidation/osnet/osnet-incorporation
Installed:
Proposed:
Latest:
//pkg5-nightly/
consolidation/ips/ips-incorporation
Installed:
Proposed:
Latest:
Format 2 Examples
=================
//solaris/consolidation/osnet/osnet-incorporation
entire
Installed:
Proposed:
Latest:
//on-nightly/consolidation/osnet/osnet-incorporation
Installed:
Proposed:
Latest:
//pkg5-nightly/consolidation/ips/ips-incorporation
Installed:
Proposed:
Latest:
Format 3 Examples
=================
Publisher: solaris
Package: consolidation/osnet/osnet-incorporation
Installed:
Proposed:
Latest:
Publisher: on-nightly
Package: consolidation/osnet/osnet-incorporation
Installed:
Proposed:
Latest:
Publisher: pkg5-nightly
Package: consolidation/ips/ips-incorporation
Installed:
Proposed:
Latest:
Format 4 Examples
=================
Publisher: solaris
Package: consolidation/osnet/osnet-incorporation
Installed:
Proposed:
Latest:
Publisher: on-nightly
Package: consolidation/osnet/osnet-incorporation
Installed:
Proposed:
Latest:
Publisher: pkg5-nightly
Package: consolidation/ips/ips-incorporation
Installed:
Proposed:
Latest:
Format 5 Examples
=================
solaris packages:
consolidation/osnet/osnet-incorporation
Installed:
Proposed:
Latest:
on-nightly packages:
consolidation/osnet/osnet-incorporation
Installed:
Proposed:
Latest:
pkg5-nightly packages:
consolidation/ips/ips-incorporation
Installed:
Proposed:
Latest:
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): ...
That would be fine with me. What I'm trying to do is ensure that there's
no implication that upgrading to a version older than latest is an error.
# 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?
Yes, just as running 'pkg update' that results in no updates currently
exits with code 4 :-)
I don't remember the original reasoning behind that, but perhaps Bart,
Danek, or someone else does.
Of course, that doesn't mean that I have continue to extend that
behaviour if we view it as undesirable. Here are the current exit codes
for reference:
EXIT STATUS
The following exit values are returned:
0 Command succeeded.
1 An error occurred.
2 Invalid command line options were specified.
3 Multiple operations were requested, but only some of
them succeeded.
4 No changes were made - nothing to do.
5 The requested operation cannot be performed on a live
image.
6 The requested operation cannot be completed because
the licenses for the packages being installed or
updated have not been accepted.
7 The image is currently in use by another process and
cannot be modified.
99 An unanticipated exception occurred.
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)?
I assume you're referring to which order I print the publishers and
their packages that are changing. In that case, I had chosen lexical
order specifically since that makes it easier to find things in the
output for most users I think, rather than publisher search order.
What's the reasoning for showing them in publisher search order instead
of lexical order?
# 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.)
They're actually aligned, either my mail client or yours destroyed the
alignment :-)
The fields are supposed to be aligned with *leading* whitespace like this:
Installed: version
.Proposed: version
...Latest: version
-Shawn
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
