--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/doc/es-requirements.txt Thu Apr 05 17:41:56 2007 -0700
@@ -0,0 +1,26 @@
+
+pkg
+ENTERPRISE SYSTEM REQUIREMENTS
+
+1. High level requirements.
+
+In no particular order.
+
+- multi-install Some packages must be able to be installed multiple
+times (in separate locations) on the filesystem.
+
+- non-root install
+
+- multi-platform Includes Windows.
+
+2. Initial assessment.
+
+Multi-install and non-root install are handled by the user image
+type, which allows a per-user install with a separate pkg client cache.
+The user image is defined by an image configuration specifying its type,
+its root directory, and its parent image (for satisfying non-relocatable
+packages).
+
+Not sure how to proceed on the Windows requirement. Most of the current
+design is portable across POSIX/ELF systems.
+
--- a/doc/flavours.txt Wed Apr 04 22:40:52 2007 -0700
+++ b/doc/flavours.txt Thu Apr 05 17:41:56 2007 -0700
@@ -1,10 +1,62 @@
pkg
-FILE FLAVOURS IN A PACKAGE
+FLAVOURS IN PACKAGES
+
+1. Kinds of flavour
+
+ Little flavours: flavours that affect individual files within a
+ package.
+
+ Big flavours: flavours that affect an entire package. Introduction
+ of a big flavour can cause a conflict with the versioning algebra,
+ so we attempt to avoid them.
+
+2. Little flavours
platform
+
ISA (particularly need to know i386 on i86pc vs amd64 on i86pc)
+
debug/non-debug
+
compatibility
(for shipping non-bleeding edge .so.x.y.z copies, perhaps)
+3. Big flavours
+
+built-on release
+
+ One problem we may run into is packages that have been built on a
+ release newer than that on the image. These packages should be
+ evaluated as unsuitable for the image, and not offered in the graph.
+ There are a few ways to handle this case:
+
+ 1. Separate repository. All packages offered by a repository were
+ built on a known system configuration. This change requires
+ negotiation between client and server for a built-on match
+ condition. It also means that multiple repositories are needed
+ for a long lifecycle distribution.
+
+ 2. Big flavours. Each package comes in a built-on flavour. This
+ means that clients move from flavour to flavour triggered by
+ conditions set by the base package on the client. Another
+ drawback is that it becomes impossible to request a specific
+ package by an FMRI, without additional knowledge.
+
+ 3. Additional version specifier. We could extend
+ release,branch:timestamp to release,built,branch:timestamp--or
+ fold the built and branch version together. Since the built
+ portion must reserve major.minor.micro, that means we move to a
+ package FMRI that looks like
+
+ [email protected],5.11.0.1:timestamp
+
+ This choice looks awkward. We could instead treat the built
+ portion as having a default value on a particular client. Then
+ the common specifier would be
+
+ name@release[,build]-branch:timestamp
+
+ build would be the highest available valid release for the
+ image.
+
--- a/doc/versions.txt Wed Apr 04 22:40:52 2007 -0700
+++ b/doc/versions.txt Thu Apr 05 17:41:56 2007 -0700
@@ -23,8 +23,25 @@
V
pkg:///sunos/[email protected]:[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 flavours 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.