Skip to main content

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.

Jump to: navigation, search

Difference between revisions of "Equinox/p2/Plan/3rd party installers on Linux"

< Equinox‎ | p2‎ | Plan
(P2 requirements processing)
(P2 requirements processing)
Line 54: Line 54:
 
# Security updates scenarios are postponed now.
 
# Security updates scenarios are postponed now.
 
= P2 requirements processing =
 
= P2 requirements processing =
 +
Dropins install everything as optional, which rules out the problem with duplicated bundles. This will not work for droplets, because removing one bundle would cause a removal of the entire droplets. So it is necessary to group artifacts that appear more than once in an ORed "tier", and create a dependency from the Droplet IU to the tier instead of to the particular bundle.
 +
 
Considering that we have available following repos (with installable units):
 
Considering that we have available following repos (with installable units):
 
* Profile  (a,b,c,d)
 
* Profile  (a,b,c,d)

Revision as of 05:45, 1 July 2013

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.


Implications

External dependencies

  • feature.xml may contain version ranges rather than specific version when it comes to the external dependencies.
  • feature patches may be generated on the fly.

Solution description

  1. A droplet should be a repository in a runnable form, because
    1. generating repositories on the fly is very expensive. See the existing dropins mechanism, featuring 30sec delay in some cases.
    2. generating repositories is also expensive in terms of the development code - there is no code we could reuse here, except dropins, which seems to generate a repo per plugin.
  2. After a repository is read, it will be queried for all installable units. Fake installable unit will be created to wrap all installable units from the repo. All installable units will get a requirement to the fake unit to achieve the all-or-nothing scenario.
  3. Security updates scenarios are postponed now.

P2 requirements processing

Dropins install everything as optional, which rules out the problem with duplicated bundles. This will not work for droplets, because removing one bundle would cause a removal of the entire droplets. So it is necessary to group artifacts that appear more than once in an ORed "tier", and create a dependency from the Droplet IU to the tier instead of to the particular bundle.

Considering that we have available following repos (with installable units):

  • Profile (a,b,c,d)
  • Droplet1 (d,e,f)
  • Droplet2 (d,e,g)
  • Droplet3 (h,i)

we should get following installation requirements:

  • common-d (Droplet1:d OR Droplet2:d OR Profile:d) is installed
  • common-e (Droplet1:e OR Droplet2:e OR Profile:e) is installed
  • Droplet1 (common-d AND common-e AND Droplet1:f) is installed
  • Droplet2 (common-d AND common-e AND Droplet2:g) is installed
  • Droplet3 (Droplet3:h AND Droplet3:i) is installed

Back to the top