Community
Participate
Working Groups
P2 has no support that makes it possible to influence the order in which units are installed. The planner fills the plan without doing any sorting. When expanding p2's usage beyond OSGi and bundles, it's increasingly common that units must be installed in dependency order, leaf first. It would be great if p2 had some support for this and I would like to discuss what a good solution for that could be in this bugzilla.
Dependency order makes sense. I worry about the performance of the sort, though.
Just to mention it: http://en.wikipedia.org/wiki/Topological_sorting We use something similar to apply a order on extensions.
> Dependency order makes sense. I worry about the performance of the sort though. The sort is not too hard too perform. Topological sorts are here for that and we already have an implementation of something like that in PDE Build to compute the compilation order. My "concern" is more around the correctness of the result in the presence of install, uninstall and update. since for example we probably want first to proceed the uninstall in the root to order and then process the install in the reverse order.
(In reply to comment #3) > My "concern" is more around the correctness of the result in the presence of > install, uninstall and update. since for example we probably want first to > proceed the uninstall in the root to order and then process the install in the > reverse order. Why should the uninstall not be done in the same order as install? If A requires that B was already present when installing, then the same is likely the case when removing A (it may need something in B to be properly uninstalled) - or did I misunderstand the "concern" ?
For the simple case you have A depends on B. B lays down some file, A configure things in there. In this case, as discussed on the ML, we want to install B, then A. But I would assume that at uninstall time we want to first uninstall A (so the uninstall is actually done cleanly) and then uninstall B. IIRC, debian gives some details on how they order things, there may be some ideas there.
Sounds to me like you say the same thing. Uninstall in reverse order of install which seems natural. An uninstall is a reverse install, no?
(In reply to comment #6) > Sounds to me like you say the same thing. Uninstall in reverse order of install > which seems natural. An uninstall is a reverse install, no? yes - my post was not well phrased :)
I have some ideas on how to implement this so if no one objects, I'll take a stab at it.
I can make a case for why we need this for a project that I am working on. As part of the feature installation, we have a custom touchpoint that installs an RPM. Even though we basically mirror the dependency information from the RPM into the features, we still have to revert to using the "--nodeps" flag as part of the installation because of the out of order installation. This works, but since nodeps masks underlying problems with the RPM dependencies, we must also test the manual RPM installations to make sure that it does not cause any issues.
(In reply to comment #8) > I have some ideas on how to implement this so if no one objects, I'll take a > stab at it. You are welcome to do so :)
(In reply to comment #9) > I can make a case for why we need this for a project that I am working on. As > part of the feature installation, we have a custom touchpoint that installs an > RPM. Even though we basically mirror the dependency information from the RPM > into the features, we still have to revert to using the "--nodeps" flag as part > of the installation because of the out of order installation. This works, but > since nodeps masks underlying problems with the RPM dependencies, we must also > test the manual RPM installations to make sure that it does not cause any > issues. This is very interesting, you should be able to map all the dependencies in an RPM to p2. The only difficulty maybe in comparing the version numbers though I think the omni version format should accomodate for RPM like versions.
(In reply to comment #11) > ... The only difficulty maybe in comparing the version numbers though > I think the omni version format should accomodate for RPM like versions. That was one of the objectives when it was designed, so no problem there. I think there might even be an example of it...
The branch sortingOperands has some initial code (http://git.eclipse.org/c/equinox/rt.equinox.p2.git/log/?h=sortingOperands)
I checked out this patch. Looks like it can't be compiled due to miss some files. (In reply to comment #13) > The branch sortingOperands has some initial code > (http://git.eclipse.org/c/equinox/rt.equinox.p2.git/log/?h=sortingOperands)
I don't think the need for order has ever arrived in practice.
