[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [tycho-dev] [discuss] tycho repository layout and metadata format
|
On 11-05-31 11:15 AM, Sievers, Jan wrote:
Not sure I understand. Does this "bill of materials" list all target
platform IUs or does it provide additional constraints to help the
resolver choose among multiple versions?
yes, the idea was to have a locked-down list of IUs, each IU has a fixed version (perfect version match).
If it's not in the list, it won't be resolved.
Together with artifact immutability this guarantees build reproducibility if we build against one "global" repo that keeps aggregating new versions.
One of aspects of build reproducibility is ability to make small changes
to the project, to produce a bugfix for an old release for example. This
implies ability to make small changes to target platform definition and
expect corresponding small changes to resolved target platform. I don't
think resolved target platform "snapshot" provides this property.
Actually we value strict build reproducibility over ease of use
for doing patch releases. E.g. if I want to do a patch release of my product and in this patch release I need to consume
a newer version of a 3rd party library (and possibly its transitive dependencies), I have to go and change this list of IUs.
IMHO it's OK if this is not cheap as long as reproducibility is guaranteed.
How do you plan to define and manage the list?
* as a set of p2 resolution constraints that resolves to the same set of
IUs regardless of repository contents. this then used as input to
project dependency resolution (at least logically, this can be
implemented in single p2 resolver invocation). As I mentioned, I do not
know how to verify if set of p2 resolution constraints is guaranteed to
produce the same result.
* as a list of IUs that is then fed as p2 resolver input. how do you
plan to produce and manage the list in this case? target platforms can
easily have 1000x of IUs, so I don't think it is feasible to manage by
hand. if the list is initially resolved from some top-level constraints
(eclipse sdk 3.6.2, wtp 3.0.2, m2e 0.12.1, etc) than re-resolving this
list for a single dependency change may result in arbitrary large
changes to the resolution result.
--
Regards,
Igor
