Source code file content
23731111 pkg-gate syntax_check should remove temp files after byte-compilation
24527406 Some single test cases fail to run without previous time estimate
Size: 4700 bytes, 1 line
A package is a labelled time series of collections of objects.
That is, over time, we expect to see something like
| on-branch transition
pkg:///email@example.com,1:[hex-timestamp-2] --> additional on-branch transitions
| branch upgrade
pkg:///firstname.lastname@example.org,2:[hex-timestamp-3] --> additional branch upgrades
| micro release upgrade
pkg:///email@example.com,1:[hex-timestamp-4] --> additional micro release upgrades
| minor release upgrade
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 -> 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
and wanted to go to the latest revision on this branch, we would
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 firstname.lastname@example.org,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 email@example.com
pkg get firstname.lastname@example.org
we would get a release constraint, which should tell us that we need
to request an update to email@example.com. This release constraint
comes from the fact that release ownership is held by a restricted set
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 firstname.lastname@example.org,1.12
The administrator can then pkg delete site/workstation-cfg (or pull
down an updated version lacking the "incorporate email@example.com,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.
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
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
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
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.