[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [tycho-dev] [discuss] tycho repository layout and metadata format
- From: Igor Fedorenko <igor@xxxxxxxxxxxxxx>
- Date: Thu, 16 Jun 2011 15:37:32 +0400
- Delivered-to: firstname.lastname@example.org
- User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:220.127.116.11) Gecko/20110414 Thunderbird/3.1.10
I believe if the following two conditions are true, then regular slicer
and planner and permissive slicer with considerOnlyStrictDependency=true
will all produce the same resolution results regardless of remote
repository contents (assuming IUs stay immutable, of course)
1. each IU is required by at least one IRequiredCapability with strict
2. there are no "dangling" optional requirements
On 11-06-16 3:15 PM, Oberlies, Tobias wrote:
Sorry. IMHO using something non-deterministic (like the p2
planner on a mutable p2 repository) and then adding constraints
to it will _not_ yield a reproducible build.
It will work if there is only one possible solution to the problem.
So it is theoretically possible to start with non-deterministic
target platform and add enough constraints to essentially make all
dependencies strict. I ran some prototypes couple of years ago. If
project target platform is defined in terms of eclipse features,
for example, then number of additional constraints necessary to
make resolution fully reproducible is relatively small.
But we are obviously talking about different ways of "defining in
terms of features".
If you feed feature IUs into a PermissiveSlicer with
considerOnlyStrictDependency=true, the resolution is reproducible
without any additional constraints.
If you want to be able to feed your target platform configuration
into a normal Slicer, you need to additionally define the versions of
all non-strictly required IUs. We had implemented this approach for
our proprietary build system, but we found it failing recently when a
feature patch was added to a p2 repository. (I still need to report
this as p2 bug ...).