Laszlo (Laca) Peter wrote:
Hi Liane,
Some questions just so I understand what's being proposed.
On Wed, 2009-10-28 at 07:40 -0700, Liane Praza wrote:
- 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.
In Desktop, we are planning to rebuild only what's changed,
and what needs to be rebuilt as a result of a change in another
component. Would we publish an incorporation that includes
package versions from different "builds"?
How is testing done to ensure that, say, new pidgin works with old
libdbus-glib? It's the collection that developers and test orgs
validate that should be incorporated. If you're testing the mix of
packages, then that's indeed what should be incorporated.
(Not directly relevant to this question, but, doesn't having the
gate deliver only what's changed mean that for some ./configure
environments that the gate incremental build might produce something
different than a fresh build does, if a package hadn't changed but a
new library was delivered which was picked up by ./configure? How
are you evaluating what's changed?)
- 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
This build versioning will not make sense if we don't rebuild the
world at regular intervals. It might make more sense for individual
packages have their own build numbers, incremented each time they
are rebuilt. (This would be analogous to RPM's Release tag.)
In the case if consolidations that rebuild everything, this number
can be the same for all packages and it can be the build #.
The build number really is just an all-consolidation-common
monotonically increasing number. I agree that it has the potential
of being confusing if JDS is delivering both 126 and 127, but it
does reflect the reality -- "the last build this package was
delivered in". Let me think a little about this -- I still need to
have conversations with Bart and Stephen and continue considering
Danek's comments, so I'll come back with an updated proposal, or at
least new justification behind the existing one based on the
questions raised.
liane
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
