John Plocher wrote:
> The IPS/pkg repository and associated packaging system must
> have the following abilities:
>
> 1. It must allow packages to be tagged with an "expectation
> level" taken from the (evolving) set of
> [Sandbox, Prototype, Experimental, Preferred, Core]
> 2. It must treat these expectation levels as namespace
> qualifiers, such that packages of the same name may
> coexist in a repository with different expectation levels
> 3. It must allow the user to select which expectation
> level(s) to choose packages from for installation
One ability it does have that affects archictecture is a much
better handling of package versioning and dependencies.
I know I've argued with John before over his assertion that the
WOS is a collection of consolidations with different Release
levels - some Major, some Minor, etc - while that's theoretically
been possible before, we've never had the tools or process to have
different release levels.
IPS however improves our tools to make it possible to choose
different release types on a package basis - only install
Micro/Patch upgrades (bugfixes only) to the kernel while
accepting Major upgrades to your desktop environment. Since
package dependencies will be able to specify versions instead
of just an implicit requirement of the version of the package
shipped in the same media kit, the possible combination matrix
grows.
What we have to figure out is if we will adjust our processes
to handle this and how, at both the architectural and support
level - we may be able to say that a update to bash that breaks
command line syntax is allowed in a bash package release to the
repository that identifies itself as a new major version, but
Sun and any other distro makers may not support combining that
with their long-term-support distro set, only their fast-and-furious
distro.
One major problem with this is that like Sun's own marketing,
many others don't accept the Sun release taxonomy - incompatible
changes may be made without incrementing the largest version
number, or the largest version number may be incremented to
indicate a marketing splash without incompatible change.
Thus if we want to support this, we need to figure out some
way of tagging new versions with what type of change they are
compared to previous ones - and that still depends on knowing
the interface taxonomy of the various interfaces.
(BTW, when reading the Release Taxonomy doc to verify my memory,
it strikes me that any document which uses as an example the OS
that installs on a Sun-3 via 1/2" tape is going to seem rather
dated to many readers. It also seems like something we've
drifted from in several other respects, but I'm not volunteering
to update it to the new world.)
--
-Alan Coopersmith- alan.coopersmith at sun.com
Sun Microsystems, Inc. - X Window System Engineering
