[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [cross-project-issues-dev] dependencies, build and P2
- From: Eike Stepper <stepper@xxxxxxxxxx>
- Date: Sun, 19 Dec 2010 09:08:05 +0100
- Delivered-to: firstname.lastname@example.org
- User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:220.127.116.11) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7
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 really like Thomas' suggestion, except I'm not sure how the +0 part would work. We'd essentially have to include all of the Orbit bundles in the base platform. The only other alternative would be to have some sort of iterative build where at step 0, we find (very liberally) all of the dependencies used by Indigo builds, but of course that creates a recursion problem.
We'd still need to be wary that our build outputs don't become dependent on the build infrastructure itself. That's unavoidable to a certain extent, but I think it would be really useful to have say a voluntary Helios (train version - 1) aggregator that people could use to ensure that their project was still compatible with Helios if that was the project aim.
On Dec 18, 2010, at 3:04 AM, Eike Stepper wrote:
Oh, I seem to understand now. That would enable us to remove any mention of Orbit bundles/features altogether from our own feature.xmls because the release train repo would include them and our bundle manifest dependencies would be used by p2. Great!
cross-project-issues-dev mailing list