Community
Participate
Working Groups
Although the p2 syntax allows to construct cases where this wouldn't work, I think that in what is done within the Eclipse ecosystem, it should be possible to create a provisioning plan for multiple ws/os/arch triples at once. The uses cases for this feature are: - Installation for multiple platforms (requested bug 303490). - Multi-platform dependency resolution with p2 (e.g. used by Tycho)
What do you want to do with the resulting plan? Would you want to know which IU has been brought in by which os/ws/arch? Why not resolve many times and combine the plans? For #303490, the real difficulty is not in the planning but in the layout of files such that they don't override each others.
(In reply to comment #1) > What do you want to do with the resulting plan? Would you want to know which IU > has been brought in by which os/ws/arch? The plan is for example used to create a self-contained p2 repository for an RCP application. For this, it is irrelevant for which os/ws/arch an IU is needed. > Why not resolve many times and combine the plans? This is what Tycho currently does: a plan is created for each triple, and the union of the plans is taken. This works insofar as it is guarantees that it is possible to install for each ws/os/arch for which a plan was created. However we ran in to the unfortunate situation that the planner found the optimal solution for one ws/os/arch, but a sub-optimal solution for another triple, resulting in a p2 repository with two versions of a non-os-specific feature (org.eclipse.rcp.source.feature.group) and only either can be installed for a concrete triple (bug 356437). Since p2 cannot guarantee to find the optimal solution, we would at least like to have a consistent solution across ws/os/arch. This could be achieved with a single plan for multiple ws/os/arch.
> > Why not resolve many times and combine the plans? > This is what Tycho currently does: a plan is created for each triple, and the > union of the plans is taken. This works insofar as it is guarantees that it is > possible to install for each ws/os/arch for which a plan was created. However > we ran in to the unfortunate situation that the planner found the optimal > solution for one ws/os/arch, but a sub-optimal solution for another triple, > resulting in a p2 repository with two versions of a non-os-specific feature > (org.eclipse.rcp.source.feature.group) and only either can be installed for a > concrete triple (bug 356437). Since p2 cannot guarantee to find the optimal > solution, we would at least like to have a consistent solution across > ws/os/arch. This could be achieved with a single plan for multiple ws/os/arch. There are different ways to control how hard p2 will look for the optimal solution. I would appreciate if you could open a bug report with the set of IUs that were causing pbs and we could see from there. The other thing is that even if it was possible to pass in all the os/ws/arch at once, you could run into different issues where conflicting versions of a singleton would apply for one combination and not for the other, thus resulting in failing to find a solution.
(In reply to comment #3) > There are different ways to control how hard p2 will look for the optimal > solution. I would appreciate if you could open a bug report with the set of IUs > that were causing pbs and we could see from there. I tried to reproduce the problem without internal content, but unfortunately it didn't work (see bug 356437). Do you have an "anonymizer tool" that would allow me to replace private IDs in the p2 metadata? > The other thing is that even if it was possible to pass in all the os/ws/arch at > once, you could run into different issues where conflicting versions of a > singleton would apply for one combination and not for the other, thus resulting > in failing to find a solution. I am aware of this problem, but I suppose this should be a rare issue. I don't think that many people will include different versions of bundles on different platforms. This doesn't seem to make much sense.
This issue seems to have died.
