Requirements gathering for new packaging system
-----------------------------------------------

Some of these requirements will be satisfied in part by the use of ZFS
as a root filesystem.

In no particular order:

A new packaging system must:

* replace existing patching/upgrade/live upgrade/Jumpstart/Jet/SUC/... 
  functionality; there should be one way of managing all software change on
  Solaris 11.

* allow fine grain control of installation contents to support minimization
  A customer should be able to select the desired functionality, and have the
  system bring in the closure of the dependency graph.
  
* support the installation of packages to a directory for diskless and Xen
  configs.

* be repository based to faciltate efficient software distribution.

* support the user's connection to multiple repositories to provide
  different types of software, newer software, different vendors/suppliers,
  etc.
  
* deal with zones:
	* maintain global zone, whole root zones in sync
	* cope w/ directory level split between global and local zones, or
	  eliminate them.

* allow a package to be installed in alternative (non default) locations.

* allow the installation of multiple instances/revisions of the same package
  in different locations.

* manage package dependencies in multiple ways:
	* allow a set of packages to be managed as a group; all packages
	  must transition together.  Groups may include other groups.
        * allow specification of a minimum version level
	* dependency graphs need not be acyclic
	
* permit the selection of alternative software streams available from a single
  repository.

* permit the "tagging" of packages with interesting information such as
  external packaging version number, features provided (at least partially)
  by this packages, etc.

* permit the creation of alternative package branches to represent either early
  platform introduction or customer-specific fixes that are later merged into
  the mainline.

* manage updates to client system in a transactional fashion; either we run the
  old bits or the new bits, never some of each.

* support secure upgrading through firewalls, etc, w/o special handling,
  ports opened, etc, on the client side.  It must be possible to both allow
  and disallow anonymous access to the repository, and offer fine grain access
  controls.

* be robust in the face of filesystem damage on the client side.  It must be
  possible to identify where the system doesn't match the packaging information,
  and to be able to repair any damage by restoring damaged components from the
  repository.

* be open source, and included in OpenSolaris.  All the tools necessary to build
  and distribute OpenSolaris via a repository should be part of OpenSolaris.
  
* support interactive development.  A developer should be readily able to 
  create a new repository, make changes, build, commit the changes to the
  repository and update his machine with those changes and reboot.  
  
* be of acceptable performance.  Upgrade operations should not reacquire files
  already in place on the system.  As much as possible, packaging operations 
  should be order (1) rather then order(number of zones).  Packaging operations
  should not be significantly affected by the number of packages already 
  installed on the system
    
A new packaging system must not:

* require changing the build system of consolidations contributing to 
  software respository.  Different parts of OpenSolaris build in many different
  ways; forcing them all to be the same is unacceptable.

* require the use of non-local resources for clients; security conscious 
  companies must be able to run their own repositories completely disconnected
  from any external networks.