A spoonful of syntactic sugar

With the putback of changeset 2224 to the pkg(5) gate, pkg(1) and the other parts of the package system now provide convenient ways for a user to specify the latest version of a package, and to specify fully-qualified package names without having to use the formal FMRI scheme.  These changes are also available in build 159 and later.

What changed?

pkg(5) programs such as pkg(1) now provide a way for users to specify that the latest version of a package should be used for an operation (such as install or update) without having to determine what the latest version is first and then specifying it manually.  The reason this matters is because the input to operations such as install or update match all versions of a package if a version is not specified, and then the solver will determine the newest version that can be installed.

This behaviour, although intentional, can sometimes be surprising to users as they may not realise that the dependency relationships between packages already installed may prevent installing the latest version of a package.  In such cases, an older version of a package than the user was expecting may be installed as it is the only version that can satisfy dependencies of packages already installed.

To provide users a way to request that pkg(1) install or update to the latest version of a package, support for specifying the version of a package as '@latest' was added.  This allows the user to direct pkg(1) to require that the solver install or upgrade to the latest version of a package, which in turn will cause the operation to fail with reasons why if it cannot.

As an example, let's say that there was a change in the build 161 version of the shell/zsh package that was desired, but the system is currently running build 160.  When a user execute 'pkg install shell/zsh' on that build 160 system, the solver will evaluate each version of the shell/zsh package that matches what the user specified.  In that case, pkg(1) would match the versions for builds 151-161 and pass those to the solver for evaluation.  The solver would then determine that the build 160 version of shell/zsh should be installed:

# pkg install zsh 
               Packages to install:     1
           Create boot environment:    No
              Rebuild boot archive:    No
Changed fmris:
  None -> pkg://solaris/shell/zsh@4.3.10,5.11-0.160
Services:
  None

As can be seen from the output above, the solver (as expected) determined that the build 160 version of zsh should be installed.  Now what if the user really wanted the build 161 version?  Well, they could explicitly request the 161 version by saying 'pkg install shell/zsh@\*-0.161'.  However, what if they didn't know that the build 161 version was the latest?  By using the new '@latest' syntax, they could explicitly request that the latest version be installed:

# pkg install shell/zsh@latest
pkg install: No matching version of shell/zsh can be installed:
  Reject:  pkg://solaris/shell/zsh@4.3.10,5.11-0.161
  Reason:  This version is excluded by installed incorporation pkg://solaris/consolidation/sfw/sfw-incorporation@0.5.11,5.11-0.160

Now in the case above, the solver tells them why the latest version can't be installed -- because the dependency relationship declared by the sfw-incorporation says the 161 version isn't acceptable.  So it should be clear why that isn't the default behaviour of the system -- sometimes the latest version is not the version that should be (or can be) installed.

Likewise, if a user was trying to update all of their packages to the latest version and wanted to determine exactly why that particular combination of packages couldn't be updated to, they could say:

 pkg update '\*@latest'

Another change made was to allow users to specify package names without having to type the 'pkg:' portion of a package FMRI or pattern.  For example, suppose that you have two packages named 'sunstudio' and 'developer/sunstudio'.  Normally, when pkg(1) is asked to list 'sunstudio' it would list packages with names ending in '/sunstudio' or that are 'sunstudio':

 $ pkg list sunstudio
NAME (PUBLISHER)     VERSION         STATE      UFOXI
developer/sunstudio  12.1.1-0.111    known      -----
sunstudio            12.1.1-1        known      --r--

If a user only wanted to list or install the 'sunstudio' package, they would have had to specify the package name like this:

 $ pkg list pkg:/sunstudio
NAME (PUBLISHER)     VERSION         STATE      UFOXI
sunstudio            12.1.1-1        known      --r--

...or like this:

 $ pkg list pkg://opensolaris.org/sunstudio
NAME (PUBLISHER)     VERSION         STATE      UFOXI
sunstudio            12.1.1-1        known      --r--
 
  

However, users may now specify the same package names or patterns to pkg(5) programs without the 'pkg:' in one of the following ways:

 $ pkg list /sunstudio
NAME (PUBLISHER)     VERSION         STATE      UFOXI
sunstudio            12.1.1-1        known      --r--

...or like this:

 $ pkg list //opensolaris.org/sunstudio
NAME (PUBLISHER)     VERSION         STATE      UFOXI
sunstudio            12.1.1-1        known      --r--

While the changes described above may not seem significant, it's a spoonful of syntactic sugar that makes life with the packaging system a little easier.

Comments:

Thank you for this update! From the risk-mitigation perspective, is there (or, could there be?) a way to have the ability to roll-back and revert to "@latest-1", for example, if the latest rev of the pkg was found to be improper - so as to go back w/out having to fallback on beadm & friends ?

Posted by Isaac Rozenfeld on March 16, 2011 at 10:53 AM CDT #

The 'pkg update' command already allows you to update a package to an arbitrary version. You just specify the older version you want it to update the package to.

While the '-1', '-2', etc. notation you suggest might be interesting, I believe it is better to require users to be explicit in their requests for downgrading packages. It's not an operation that should be taken lightly.

As for the package system itself, keep in mind that is currently published with each new OS build. That means that essentially you can't just downgrade the package system -- everything would have to be downgraded.

Posted by Shawn Walker on March 16, 2011 at 11:03 AM CDT #

Post a Comment:
Comments are closed for this entry.
About

user12609878

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today