...
Of couse with opensolaris you get the code every couple of weeks so
you get to see the latest technology before the patches are
availble for s10.
As I said in my original post, the reason for the current behaviour
is due to the way Solaris has been released in the past; that
stability is one of the things that sets Solaris apart from many
Linux installations.
*We* all know that showrev -p shows the current patch status, but if
the user is trying to determine whether the Perl version they have
installed is the latest then, as in your example, getting 8.0.4 + the
list of patches wont be helpful (although, to be fair, they could use
perl -v).
From a Linux users perspective they are used to installing a package
and usually getting clear idea of which package they are installing
and what version number it is, under Solaris it isn't always clear.
To give you a good example, if I check the Sun installed version of
bash I get the following:
PKGINST: SUNWbash
NAME: GNU Bourne-Again shell (bash)
CATEGORY: system
ARCH: sparc
VERSION: 11.10.0,REV=2005.08.26.07.05
BASEDIR: /
VENDOR: Sun Microsystems, Inc.
DESC: GNU Bourne-Again shell (bash) version 3.0
PSTAMP: sfwnv20050826071340
INSTDATE: Sep 27 2005 18:03
HOTLINE: Please contact your local service provider
STATUS: completely installed
FILES: 3 installed pathnames
2 shared pathnames
2 directories
1 executables
1438 blocks used (approx)
A quick look would reveal that the version of bash installed is
11.10.0. There is no such version of bash, and actually the version
information I really want is embedded into the description.
The way Solaris was updated and managed in the past is what has led
to this situation, and those of us who have been there since Solaris
understand it, but I think it is far from an ideal situation.
There is also this odd disparity in the tools in that we have a suite
of package management tools (pkg*) that add, remove and show info
about packages, but they are incapable of giving me a quick rundown
of the versions installed - pkginfo -v requires a package name,
pkginfo -l lists everything or requires a name. To get that
information, I need another tool (smpatch) and then the information
is shown in terms of the currently installed version and any patches
that apply to it, which again is less than ideal.
Even if pkginfo did have helpful output then as shown in the case of
bash, the version of 11.10.0 is meaningless, all it tells me is the
version of the package, not the version of the underlying application
that is installed, which is really what I'm more interested in.
Blastwave is better at this, because it lists the version number of
application as the version number of the package, but once you start
using Blastwave that makes two systems suites of packages you have to
keep up to date, even though behind the scenes they are both storing
and installing through the same package management interface.
Now that we can currently get packages from multiple places (the
original Sun packages, Sunfreeware and Blastwave, just for example),
then managing packages becomes complex again.
The moment I start using pkg-get and Blastwave, to keep up to date, I
have to run smpatch *and* pkg-get. Even worse is that it's possible
to install the same software package (i.e. bash, zsh) from Sun,
Blastwave and Sunfreeware. This is true even though technically the
packages are managed by the same system, but the tools are installed
in different directories.
By comparison, nearly all Linux installations that provide automatic
updates have a simple way to allow you to check current versions, and
version numbers of installed packages generally refer to the version
number of the product that has been installed, not some (arbitrary)
number used by the operating system.
I also have only one source to get and update that information. I
know choice is great and I think the work of Blastwave, Sunfreeware
and others is excellent, but that fragmentation could in the long run
be a problem.
I've just noticed Dennis's post about a pkg-get gui. That would be
great. What would be really cool is if somehow it could interact
with the sun update manager so that S10 users could have a single
gui to manage their sun patches and pkg-get packages.
On that point (as I state above) we completely agree :)
MC
--
Martin 'MC' Brown, http://MCslp.com
_______________________________________________
opensolaris-discuss mailing list
[email protected]