pkg
Expressing versions

  A package is a labelled time series of collections of objects.
  That is, over time, we expect to see something like

  pkg:///sunos/coreutils@5.11,1:[hex-timestamp-1]
                |
		| on-branch transition
		V
  pkg:///sunos/coreutils@5.11,1:[hex-timestamp-2] --> additional on-branch transitions
                |
		| branch upgrade
		V
  pkg:///sunos/coreutils@5.11,2:[hex-timestamp-3] --> additional branch upgrades
                |
		| micro release upgrade
		V
  pkg:///sunos/coreutils@5.11.1,1:[hex-timestamp-4] --> additional micro release upgrades
                |
		| minor release upgrade
		V
  pkg:///sunos/coreutils@5.12:[hex-timestamp-5]

  In this sequence, we've assumed that the client's requirement to
  remain with binaries associated with a particular build is implicit
  with the client.  As discussed in the tags and attributes note, we
  need to handle the distinction between a package built on one release
  and the same package's binaries built on another release.

  XXX Need a full example with the build_version in place.

  Each transition is constrained by the local client's decision to "stay
  on branch", "move to a newer branch", "move to a newer release".
  Both the release, the required build, and the branch can be
  "dot-separated vectors".  The timestamp is not.  That is, a full
  version is

  version -> dot_vector(,dot_vector)?-dot_vector:timestamp

  dot_vector -> digit+ ( "." digit+ )*

  timestamp -> hexdigit+

  Rollback is expected to be handled by image management.  Rollback is
  expected to be made convenient through use of ZFS.

  If we had

  sunos/coreutils@5.11,1:[hex-timestamp]

  and wanted to go to the latest revision on this branch, we would
  invoke

  pkg get coreutils

  which could upgrade other components.

  If we wanted to go from 5.11,1.x to 5.11,2 we would invoke

  pkg get coreutils@5.11,2

  (which might be the result of displaying a cosmetic version string,
  like "GNU coreutils 6.8" or something).  This operation might cause
  other components to be updated.

  If we instead did

  pkg get coreutils@5.11.1

  or

  pkg get coreutils@5.12

  we would get a release constraint, which should tell us that we need
  to request an update to base/minimal@5.11.1.  This release constraint
  comes from the fact that release ownership is held by a restricted set
  of packages.

  If coreutils had been frozen by another package, we would get, in
  response a message like

  pkg:  sunos/coreutils frozen at 5.11,1 by site/workstation-cfg@5.11,1.12

  The administrator can then pkg delete site/workstation-cfg (or pull
  down an updated version lacking the "incorporate coreutils@5.11,1"
  statement, with its implied freeze).

  pkg delete on groups removes leaf packages in the group (included via
  "pkg" statements) but leaves package dependencies untouched.

  The "pkg freeze" subcommand can place an administrative freeze on a
  specific package.  "pkg unfreeze" (pkg thaw?) can remove a freeze,
  either an administrative freeze or a freeze placed by another package.


Co-requisite packages

  We need to support a@1 <-> b@2.  This is handled as two transactions,
  so we need to allow unresolved dependencies to exist in the
  repository, _but_ the R = (a@1, ...) repository cannot offer a@1 until
  it also has b@2.  And also G (a@1, b@2) group package cannot be
  submitted.

  This requirement becomes a hint for our order of operations:
  individual package transactions, group (base and stack) transactions.


When to increment the branch number?

  On incompatible change to a private interface.

  On addition of new private interfaces.

  On addition of new public interfaces where the release version is
  constrained.

  Potentially on the addition of a newly delivered platform or ISA?


Using the (hex) timestamp as the sequence ID

  We can source a package, category/pkg, from any repository we choose
  to trust.  That is, we can do

  pkg update pkg://rosseau.sfbay/base/developer

  on a system that had a default base FMRI of pkg://opensolaris.org

  As long as the two repositories agree on the forward use of the
  release and branch version components, then the timestamp approach
  allows us to allow a system to move back and forth between multiple
  repositories.


On-build release freezes

  We may need an expression format that allows us to pin the on-build
  portion of the version space, in addition to specifying the release
  and/or branch portion of the FMRI as frozen.  Otherwise, we could jump
  from a binary compiled from one environment to that from a completely
  different compilation environment, based on only a timestamp change.