Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] dependencies, build and P2

Am 20.12.2010 00:38, schrieb Miles Parker:
n Dec 19, 2010, at 12:08 AM, Eike Stepper wrote:

Am 18.12.2010 22:57, schrieb Miles Parker:
Hmm, I think you would still want to have them in "requires", right? Because otherwise you can't be sure that all of the bundles would be included in a build that *wasn't* using the Indigo release train process.
Not sure I follow. By "included in a build" do you mean "installed in the build's target platform" or "included in the (promoted) build result"? I think the first would happen through the bundle's manifest dependencies. And the second is exactly what I currently have to do but really don't like so much. Why am I supposed to duplicate an Orbit subset? And thereby create a potential for conflicts in the release train repo or any user's installation. Am I on a wrong track?
I shouldn't have used the word "include" here. :) "provided with" is better. So in other words, if you have the "requires" then buckminster will ensure that they end up in your target platform,
My head is spinning :P

I thought this "end up" semantics are only associated with the "includes" element and that the "requires" element cause a provisioning operation (whether during build or install does not matter, with Bucky it's the same) just causes a failure if the required components are not already there. Seems I was wrong?



  and with P2 will ensure that they end up available from somewhere, i.e. you can go to the update site produced by p2 build and it will always work. I think. But buckminster and P2 should merge all of that modulo the issues we've been discussing. I don't think there is any way around this

Now remember of course that you won't have to include any requirements already specified by your dependencies so there shouldn't be any duplication per se, only an indication that you expect something to be available. See next post..

cross-project-issues-dev mailing list

Back to the top