On 1/24/12 5:08 PM, Shawn Walker wrote:
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:
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):
One other possibility. What about the "package (publisher)" layout
currently used in pkg list? e.g. entire (solaris)? Looking through
your examples below, the thing that's hardest on the eye for me is when
the publisher is on a separate line than the incorporation, and with no
labeling. I end up having to engage my brain more to differentiate
what's the publisher versus what's the package (especially with
"entire"). And I very much want to know that information. Repeating
the publisher when necessary doesn't bug me, especially if it's on the
same line as the package.
consolidation/osnet/osnet-incorporation (on-nightly)
Installed:
Proposed:
Latest:
consolidation/ips/ips-incorporation (pkg5-nightly)
Installed:
Proposed:
Latest:
Other than that, format 3/4 is most appealing to me. I'm on the fence
about the whitespace between packages. It's probably useful, but I
don't feel super strongly.
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.
Yeah, I feel like Installed, Latest, Proposed achieves that best, even.
To me then you're first printing out the invariants, then where I'm
going. Otherwise I always think I'd be re-ordering it in my brain to
determine where was I, where could I potentially go, and where am I
actually going?
(But that could just be me, I'm willing to admit.)
# 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:
4 No changes were made - nothing to do.
6 The requested operation cannot be completed because
the licenses for the packages being installed or
updated have not been accepted.
Hm, I'd fret a bit about changing the semantics of the exit code in an
update. I'll leave that decision to the core pkg team, though.
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?
I was wondering if the most preferred was the most interesting to lots
of folks, and thus if you printed in least preferred to most preferred
order, you'd end up with the most interesting thing to them closest to
their cursor.
(But, this is a nit at best. I'm not sure it matters much.)
# 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
Cool, thanks. Was probably my mail reader that confused me.
liane
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
