Source code file content
18116510 operation planning ignores removed facets if new are set at same time
Size: 3765 bytes, 1 line
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
* 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
* 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,
* deal with zones:
* maintain global zone, whole root zones in sync
* cope w/ directory level split between global and local zones, or
* 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
* 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
* 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
* 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
* 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.