* Liane Praza <liane.pr...@sun.com> [2009-10-28 15:39]:
> - 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.
Do you expect this coordination among consolidations (affecting their
build systems) to be different or more timely than current Common
Build Environment (CBE) actions?
> - 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.
Is this SUNWonbld for ON? Are there other known packages or
"infrastructure" of this type in other consolidations?
> All packages delivered to RE are expected to be governed by
> at least one incorporation delivered by the consolidation.
How should we audit or enforce this? How would "unbundled" software
be handled?
> - RE through the IPS gate tools will produce an "entire"
> incorporation which specifies all the consolidation
> incorporations.
Do you want to propose the name change now?
> - 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
Is it time to drop the leading zero? (I'd still like my "-1" symbol
first.)
> 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
^ "a", I think
> - 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.
"may not specify" -> "need not"? ("may not" usually normative.)
> 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.
Maybe add: "These incorporations are independent of group
packages used to identify feature or function boundaries."
> - 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.
"their publishers" -> "their image's publishers"?
"They then" -> "They would then"?
> - 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.
>
"nightly of" -> "nightly builds of"?
> - 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).
"newer OpenSolaris" -> "a newer OpenSolaris release"?
"and downgrade" -> "and then downgrade"?
> - 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.
"going back" -> "a return"?
> 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".
Looks good. I understood it, anyhow. :)
- Stephen
--
s...@sun.com http://blogs.sun.com/sch/
_______________________________________________
pkg-discuss mailing list
pkg-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
