On Wed 28 Oct 2009 at 07:40AM, Liane Praza wrote:
> (bcc'ed to on-ips-...@opensolaris.org If you're interested in this
> discussion, please join us over at pkg-disc...@opensolaris.org.)
>
> 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.
I have a couple of nits. High level feedback is that this
makes sense and sets clear and reasonable boundaries.
> 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.
I *think* I get what you mean here, but I might not-- I found
the wording of sentences one and two to be a little confusing. My
personal reading is:
Consolidations shall do one of the following:
(1) Produce a single incorporation which ties all packages for
the current build for that consolidation together.
All packages except for the incorporation itself must
be incorporated by this incorporation. Recommended for most
consolidations.
OR
(2) Produce multiple incorporations which tie together
subsets of packages. All packages must be a member
of at least one such incorporation. Only suited for
a consolidation which produces sets of software that
are known and tested to be truly independent.
Is that an accurate reading? For (2), I couldn't tell if
overlapping incorps. would be allowed, as this seems to run
somewhat counter to the idea of "known to be independent."
So I just wasn't sure.
Also, with the final sentence, I wasn't sure if there is a
distinction between "all packages" and "all packages delivered
to RE", and if so, what that might mean?
> - 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
For my own sanity: this is just echoing the current practice,
correct?
> - 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.
Perhaps you want to template what the user visible description
(pkg.summary) and other metadata (pkg.description) should
be for each consolidation incorporation. Otherwise it will vary wildly.
Today for entire we have:
set name=pkg.summary value="Build 126 entire incorporation"
set name=description value="Build 126 entire incorporation"
set name=pkg.description value="This package constrains package versions to
those for build 126. WARNING: Proper system update and correct package
selection depend on the presence of this incorporation. Removing this package
will result in an unsupported system."
Which is generated by src/util/distro-import/build_entire_incorporation.
> 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.
I think an interesting question is whether the system is supportable/
supported if these incorps (and entire) are removed (see pkg.description
above).
Otherwise I found it highly cogent. Thanks for writing this
up!
-dp
--
Daniel Price, Solaris Kernel Engineering http://blogs.sun.com/dp
_______________________________________________
pkg-discuss mailing list
pkg-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
