Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Equinox/p2/Plan/3rd party installers on Linux
Contents
P2 with 3rd party installers
I'd like to make this OS independent, but some issues are very distro-specific, I'll mark them accordingly.
Linux background
Linuxes have a policy of one library per system, which means that each jar is physically installed only once by a package that contains it, and all other packages using it have to 'Require' it and then properly symlink. Eclipse is no different. In Fedora, RHEL and Mageia it comes as a set of org.eclipse bundles and a set of symlinks to other dependencies. Example of symlinking:
sat4j is shipped as a separate package (sat4j), with files: /usr/share/java/org.sat4j.core.jar /usr/share/java/org.sat4j.pb.jar
Now after Eclipse is build, jars are symlinked: org.sat4j.core_2.3.5.v20130405.jar -> /usr/share/java/org.sat4j.core.jar org.sat4j.pb_2.3.5.v20130405.jar -> /usr/share/java/org.sat4j.pb.jar
Therefore if there is a security problem with sat4j it is enough to update one library (in most cases).
Yes, Eclipse is split amongst a number of packages which can be independently updated.
Use cases
Eclipse Base installation
Usually only platform is installed into a read-only area of the system.
Additional features management
Additional features are separate projects and separate packages. After deploying them to certain folders, they should start working after next Eclipse restart. When those folders are deleted, features should disappear from Eclipse installation. No additional files should be modified (like history, timestamps, etc). This is because an admin should be able to verify that his system is not compromised by doing checksums.
Eclipse updates [I]
From time to time, Eclipse or eclipse packages are updated, and the new installations overwrite the old ones. After being started, Eclipse should discover changes and update new things accordingly without bugging the user too much.
Eclipse updates [II]
Eclipse should not allow for mixing RPM installed features and traditional P2 updates from update sites. What is managed by external installer, should stay such, and P2 should not try to install/update/uninstall those things. This affects especially Eclipse updates, Migration Wizard and remediation dialog.
Eclipse updates [III]
If a user chooses to install things from the Eclipse Foundation, and they are not installed using the external installer, he should be allowed to do so. If he later installs the same package (even older one) using the installer, the installer version should take precedence over the P2 installed one.
[LINUX] Security updates
From time to time, CVE are discovered and certain dependencies are rebuild (tomcat, jetty, axis for mylyn etc). This causes a situation where a symlink target changes (usually MANIFEST.MF gets new version). Eclipse should discover that and reinstall as many things as possible.