(bcc'ed to [email protected] If you're interested in this
discussion, please join us over at [email protected].)
Hi folks,
I need to settle on a final design for the incorporations and
versions of consolidation repositories. I intend to implement
this in the importer now to ease the consolidation transition
job, as well as in the ON IPS development gate.
1. Proposal
- Consolidations will produce repositories which have
dependencies specified using pkgdep. Dependencies between
packages in the same consolidation will be specified at the
current version of the consolidation. Dependencies on system
components from outside the consolidation will be specified on
the version of the component installed at build time.
- Each consolidation will produce at least one consolidation
incorporation which ties all packages for the current build
from that consolidation together. A consolidation may choose
to produce multiple incorporations if its build and test
process produces sets of software that are known and tested
to be truly independent. No consolidations are believed to
have that infrastructure today except for a few
developer-specific pieces.
All packages delivered to RE are expected to be governed by
at least one incorporation delivered by the consolidation.
- RE through the IPS gate tools will produce an "entire"
incorporation which specifies all the consolidation
incorporations.
- Consolidations are expected to publish an appropriate version
number for each IPS package every time it is published. The
build number should increment as soon as a build opens.
The version number is part of the package FMRI after the @.
For OpenSolaris specific software, it should be:
0.5.11,5.11-0.<build #>
e.g.
0.5.11,5.11-0.127
For software from other sources which maintains its own useful
version number,
<software version #>,5.11-0.<build #>
e.g.
3.2.50,5.11-0.127
- End users do not need to care about the consolidation
incorporations. They're a convenience for developers, as well
as reflection in IPS of build/test boundaries to better
assemble a supportable surface. Other incorporations are
expected across more user-visible boundaries in the future.
2. ON-specific implementation
- ON will track the build number via a file in the repository
which the gatekeepers integrate as soon as a build opens.
i.e. when 127 opens, they push a change to say that the build
is 127. (usr/src/VERSION ?)
- Both repositories built by the ON build process (on and
on-extra) will publish an incorporation.
- SUNWonbld is special. It's expected to be able to move
independently of the rest of the system, and is tested with
this in mind. Thus, ON will also deliver an incorporation for
SUNWonbld and not include SUNWonbld in the normal ON
incorporation. Because it needs to be able to move
independently, it may not specify dependencies, or may specify
them without versions.
3. Use Cases
(From most to least common.)
- The average OpenSolaris user shouldn't have to care about any of
this. When they update, the dependencies and incorporations
should be constructed in a way that was testable and already
tested.
- A developer in any consolidation who wishes to track the nightly
builds for their consolidation would set up their publishers
to prefer a publisher which serves nightly bits for their
consolidation and leave the opensolaris.org/dev publisher intact
at a lower preference. They then "pkg uninstall entire" and
allow only consolidation incorporations to govern their
system's package surface.
When new versions of the other consolidations are published to
opensolaris.org/dev, the developer will upgrade those packages
too. Thus, tracking a consolidation continues to allow upgrade
of bits from other consolidations.
- A developer who wished to track nightly of multiple
consolidations would be able to do so with the same mechanism as
tracking a single consolidation.
- A cross-consolidation flag day is managed by requiring
developers track multiple consolidations for a single build.
- A developer may wish to install newer OpenSolaris and
downgrade to an older development workspace. That is handled
by explicitly installing the older version to a new BE. The
developer could also specifically set the version in their
workspace to publish the old bits at a new version (though
this is not generally recommended).
Direct 'downgrade' which violates version numbers is not a
requirement.
- A developer or early adopter who had been tracking nightly
builds of consolidations may wish to get their machine back
onto the normal opensolaris.org/dev release train. They can
not do so directly because the consolidation nightly is
currently publishing at build 127 when opensolaris.org/dev
is at 125 or 126 so going back to /dev is a downgrade.
They have two choices:
1. Fall back to a BE which did not use the consolidation
nightlies.
2. Delete the consolidation nightly publishers, wait for
opensolaris.org/dev to catch up to the correct build
number, and then "pkg image-update" and
"pkg install entire".
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
