P2RPM

This page tracks the work and random issues that appear during work on bug 378329 - integration of P2 and 3rd party installers (in this case RPM).

Existing problems:

P2 needs to be launched to perform installation, which does not work with RPM, because RPM cannot handle P2 exit statuses and determine whether a package was successfully installed or not. In addition to that, RPM has a concept of file ownership, and installation of one package must not change files of another one, because they will be marked then as compromised (it's a security issue).

Existing solution:

Fedora Eclipse (and some other products) use dropins approach. One folder is a place to which all bundles are copied, and then, on next Eclipse startup, P2 discover changes, constructs new configuration and load bundles.  Each RPM package contains a set of plugins to be deployed and dependencies to other packages that needs to be deployed first.

Existing solution limitations:

• Sometimes it is necessary to start Eclipse twice to get all bundles properly installed.
• Dropins mechanism is proven to deliver heuristic solutions where the amount of plugins is high.
• Dropins mechanism is silent. If something goes wrong (and that happens pretty often without obvious reason), the investigation is very time consuming.

Desired solution:

RPM (or any other installer) should be capable of deploying lists of files that should be installed by P2. P2 on startup does 3 things:

• get all bundles installed by P2 director API
• install all bundles listed in files - if this does not work, P2 should refuse to start Eclipse. It should start working again after the offending list is removed. Could we use P2 repos here? No, because repos will be gone when the package is uninstalled. We need to discover missing repo, guess which plugins belonged to it, etc, etc. Or maybe we could store those properties in a profile?
• perform regular dropins reconciliation.

+++

• easy deployment of prepackaged bundles
• instant feedback
• the 3 steps scenario will work fine for features installation and uninstallation.

---

• yet another startup step
• 3 steps reconciliation
• complex handling of complex scenario
  • uninstalling a P2 API installed feature that is a a requirement to RPM installed feature. The operation should fail.
  • update of RPM installed feature by P2 API operation . Should be forbidden.
  • uninstalling an RPM installed feature that is a requirement to a P2 API installed feature. P2 API installed feature should be uninstalled. (how to do that?)

Secondary issues:

Those issues are not a part of this work, but they affect Eclipse experience on Linux. It would be good to fix them, too:

249133: [shared] Default update site list blank in shared install
304132: [shared] Upgrading shared base causes loss of user installed plug-ins
379102: Prevent running Eclipse as root (optionally)

Past propositions:

RPM should deploy additional .info files, which Eclipse loads on startup and creates a spoofed profile in order to get P2 working.

Drawbacks: What if something is uninstalled? How can we detect if some not-dropins controlled plugins are absent? How to uninstall things from P2? What to tell user?