1N/A A package is a labelled time series of collections of objects.
2N/A That is, over time, we expect to see something like
2N/A | on-branch transition
2N/A | micro release upgrade
2N/A | minor release upgrade
16N/A In this sequence, we've assumed that the client's requirement to
16N/A remain with binaries associated with a particular build is implicit
30N/A with the client. As discussed in the tags and attributes note, we
30N/A need to handle the distinction between a package built on one release
30N/A and the same package's binaries built on another release.
16N/A XXX Need a full example with the build_version in place.
1N/A Each transition is constrained by the local client's decision to "stay
2N/A on branch", "move to a newer branch", "move to a newer release".
16N/A Both the release, the required build, and the branch can be
16N/A "dot-separated vectors". The timestamp is not. That is, a full
16N/A version -> dot_vector(,dot_vector)?-dot_vector:timestamp
16N/A dot_vector -> digit+ ( "." digit+ )*
16N/A timestamp -> hexdigit+
2N/A Rollback is expected to be handled by image management. Rollback is
2N/A expected to be made convenient through use of ZFS.
2N/A and wanted to go to the latest revision on this branch, we would
2N/A which could upgrade other components.
2N/A If we wanted to go from 5.11,
1.x to 5.11,2 we would invoke
2N/A pkg get coreutils@5.11,2
2N/A (which might be the result of displaying a cosmetic version string,
2N/A like "GNU coreutils 6.8" or something). This operation might cause
2N/A other components to be updated.
2N/A pkg get coreutils@5.11.1
2N/A pkg get coreutils@5.12
2N/A we would get a release constraint, which should tell us that we need
2N/A comes from the fact that release ownership is held by a restricted set
2N/A If coreutils had been frozen by another package, we would get, in
2N/A response a message like
26N/A down an updated version lacking the "incorporate coreutils@5.11,1"
26N/A statement, with its implied freeze).
2N/A pkg delete on groups removes leaf packages in the group (included via
2N/A "pkg" statements) but leaves package dependencies untouched.
12N/A The "pkg freeze" subcommand can place an administrative freeze on a
12N/A specific package. "pkg unfreeze" (pkg thaw?) can remove a freeze,
12N/A either an administrative freeze or a freeze placed by another package.
9N/ACo-requisite packages
9N/A We need to support a@1 <-> b@2. This is handled as two transactions,
9N/A so we need to allow unresolved dependencies to exist in the
9N/A repository, _but_ the R = (a@1, ...) repository cannot offer a@1 until
9N/A it also has b@2. And also G (a@1, b@2) group package cannot be
9N/A This requirement becomes a hint for our order of operations:
9N/A individual package transactions, group (base and stack) transactions.
9N/AWhen to increment the branch number?
9N/A On incompatible change to a private interface.
9N/A On addition of new private interfaces.
9N/A On addition of new public interfaces where the release version is
30N/A Potentially on the addition of a newly delivered platform or ISA?
12N/AUsing the (hex) timestamp as the sequence ID
12N/A to trust. That is, we can do
12N/A As long as the two repositories agree on the forward use of the
12N/A release and branch version components, then the timestamp approach
12N/A allows us to allow a system to move back and forth between multiple
26N/AOn-build release freezes
26N/A We may need an expression format that allows us to pin the on-build
26N/A portion of the version space, in addition to specifying the release
26N/A and/or branch portion of the FMRI as frozen. Otherwise, we could jump
26N/A from a binary compiled from one environment to that from a completely
26N/A different compilation environment, based on only a timestamp change.