On 01/06/12 07:56, Peter Dennis wrote:
On 01/06/12 15:41, Bart Smaalders wrote:
On 01/06/12 04:10, Peter Dennis wrote:
<snip>
END-USER EXAMPLES
=================
These examples assume 'entire' is installed and nothing has been
version-unlocked:
# pkg update -n
...
UPDATE SUMMARY
solaris
entire
Installed 0.5.11,5.11-0.175.0.0.0.2.0:20111020T143822Z
Proposed 0.5.11,5.11-0.175.0.2.0.3.0:20111201T182924Z
...
Shows an update from S11 release to the latest SRU. '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.
One other thought, while removing the timestamps, is to
attempt to translate the FMRI string to a friendly meaning:
# pkg update -n
...
UPDATE SUMMARY
solaris
entire
Installed: Solaris 11 GA
Proposed: Solaris 11 SRU#2
...
this does imply building some 'translator' somewhere.
And building into the guts of the packaging system the internal
release details of the Solaris WOS. I'd _MUCH_ rather add human
friendly version names as metadata to the packages, and display that if
available. That way if we need to change things someday, we're not
cursing ourselves quite so hard.
Yeap. I was just looking at Danek's pkg.human-version and that would
appear to be the thing that could be used which then leaves it to the
teams that deliver the packages as opposed to building stuff into the
pkg(5)code base.
In this instance the 'Installed:'/'Proposed' would print out the
Version information from the pkg.human-version ?
This was what I was hinting at in my last reply when I said I thought I
had a better way to present this information.
I think both versions need to be shown though.
-Shawn
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
