Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#45577 - [eclipse-java] Incorrect conflicts?

Attached to Project: Arch Linux
Opened by Steven Fosdick (Amphitryon) - Tuesday, 07 July 2015, 09:34 GMT
Last edited by Antonio Rojas (arojas) - Friday, 01 May 2020, 18:42 GMT
Task Type Bug Report
Category Packages: Testing
Status Closed
Assigned To Antonio Rojas (arojas)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 20
Private No



The packages eclipse-java and eclipse-cpp conflict. I am not sure this is the intention both because of the existence of a separate eclipse-common package and because programmers may well work in more than one language.

Might this be because each package says it provides "eclipse" and also conflicts with "eclipse", the latter to presumably say the 4.5 packages conflict with the 4.4 packages?

Additional info:
* package version(s)
* config and/or log files etc.

Steps to reproduce:

From an installation that has eclipse (4.4) and (eclipse-cdt) installed attempt to upgrade to testing/eclipse-java and testing/eclipse-cpp by running pacman -Syu.
This task depends upon

Closed by  Antonio Rojas (arojas)
Friday, 01 May 2020, 18:42 GMT
Reason for closing:  Won't fix
Additional comments about closing:  eclipse has been dropped to AUR due to lack of maintainer
Comment by Doug Newgard (Scimmia) - Tuesday, 07 July 2015, 14:02 GMT
This is intentional and correct. Look at the packages, they include conflicting files.
Comment by Allan McRae (Allan) - Saturday, 25 July 2015, 09:34 GMT
The should be able to be installed together - and they were until the update. It is a very, very common usage to need both installed at once. This packaging needs fixed.
Comment by Dmitriy Kargapolov (xoid) - Wednesday, 29 July 2015, 18:32 GMT
One of the purpose of packaging is to keep required patches together with stuff obtained from upstream.
Comment by Alain Kalker (ackalker) - Wednesday, 05 August 2015, 17:34 GMT
I can see the source of the confusion.

The packages eclipse-java, eclipse-cpp, eclipse-php each now stand for a self-contained Eclipse *product*, not just one or more Eclipse *features* to be added to an existing product (like the old eclipse-cdt package). This is why all of these packages provide and conflict with the eclipse (virtual) package.

The eclipse-common package merely contains files common to all of these product packages, to save disk space on the mirrors. It is _not_ a skeleton Eclipse product meant for adding features onto.
Comment by Alain Kalker (ackalker) - Wednesday, 05 August 2015, 17:38 GMT Comment by Steven Fosdick (Amphitryon) - Wednesday, 05 August 2015, 19:48 GMT
A brief read of Eclipse documentation referenced on creating products suggests it is aimed at people supplying a specialised, possibly proprietary, tool not a general purpose development environment. When such a tool was distributed and installed it would be self-contained and thus even if it contained files that were actually common to some other Eclipse-based products the product being installed would have its own copies.

If one wanted to apply that philosophy to Java and C++ developments, i.e. define each as a product then the common package approach and conflicts is not consistent with that philosophy. What would need to happen instead is that each product package would need to be self-contained and not use any filesystem paths included in the other package even if that meant duplicating 99% of the files. Despite not being very efficient on storage most people installing would probably prefer that approach to a complete inability to install both at once.

A better approach, in my view, would be retain the "core" or "common" package and go back to having packages for the relevant plugins for various languages and development tasks. The core package could contain some scripting such that as the optional packages are installed/uninstalled files that enumerate what is installed, and would therefore conflict if simply included in the option packages, would be generated automatically from what is actually installed.
Comment by Dmitriy Kargapolov (xoid) - Wednesday, 05 August 2015, 19:57 GMT
What actually happened - Eclipse developers made life of downstream packages maintainers extremely uncomfortable. I see no simple solution.
Comment by Alain Kalker (ackalker) - Thursday, 06 August 2015, 01:21 GMT
@xoid Seconded.
Eclipse is not a simple application but an entire ecosystem, with its own package manager, plugin system and dependency hell sploshed into a fishbowl. We may be thankful that the Eclipse developers made it (somewhat)[1] possible at all to install an Eclipse product package in a system area (where normal users don't have write access).

@Amphitryon Modular Eclipse packaging by distributions is _by no means_ a simple task, it involves much more than simply splitting the whole thing up in a set of plugins. There is dependency hell, not all combinations of features work (well) with the same versions of plugins, not all plugins can coexist within the installation, etc., etc.
To get an inkling of the sheer complexity involved in modular Eclipse packaging, have a look at [2].
I can entirely understand that Arch Linux, striving for mostly vanilla, unpatched packages, doesn't want to go that way.

My personal tip: if you want to use Eclipse with more than a few extra features besides those of one of the main development products, by all means download, unzip and run one of the prebuilt product packages somewhere in your home directory, then add features using the "Install new software" menu choice. Don't try and pimp a "shared" installation with lots of extra plugins and features, things will break, often in very frustrating ways.

Comment by Bill Mair (red-lichtie) - Sunday, 13 March 2016, 11:26 GMT
I've added a feature request for this but maybe my proposal should be here aa a possible fix for the reported bug. Please see:
Comment by Bill Mair (red-lichtie) - Sunday, 13 March 2016, 11:27 GMT
When upgrading eclipse I get the following error because I use java and cpp.

# pacman -Su
:: Starting full system upgrade...
:: Replace eclipse with extra/eclipse-java? [Y/n]
:: Replace eclipse-cdt with extra/eclipse-cpp? [Y/n]
resolving dependencies...
looking for conflicting packages...
error: unresolvable package conflicts detected
error: failed to prepare transaction (conflicting dependencies)
:: eclipse-java and eclipse-cpp are in conflict

This is because the packages eclipse "product" packages have overlapping files.

One suggested resolution is to only install one of the products, i.e. java or cpp and then add support for the other product via the eclipse installation mechanisms.

The way that I think it could be resolved is to have the 3 current product packages installed in their own directory and linked with standard eclipse mechanism for product extensions.

This mechanism is described here:

I think they should be installed as follows:


eclipse-common remains unchanged but for the addition of the "links" directory
add directory: /usr/lib/eclipse/links


eclipse-java is installed in to /usr/lib/eclipse-java/eclipse
add empty file: /usr/lib/eclipse-java/eclipse/.eclipseextension
add link file: /usr/lib/eclipse/links/ whose contents would then be:

name=Eclipse Java Developer Toolkit


eclipse-cpp is installed in to /usr/lib/eclipse-cpp/eclipse
add empty file: /usr/lib/eclipse-cpp/eclipse/.eclipseextension
add link file: /usr/lib/eclipse/links/ whose contents would then be:

name=Eclipse C Developers Toolkit


eclipse-php is installed in to /usr/lib/eclipse-php/eclipse
add empty file: /usr/lib/eclipse-php/eclipse/.eclipseextension
add link file: /usr/lib/eclipse/links/ whose contents would then be:

name=Eclipse PHP Developers Toolkit

Comment by Florian Latifi (flortsch) - Friday, 10 June 2016, 15:05 GMT
Wouldn't it be possible to provide a single package, which just installs the Eclipse Platform Runtime Binary.
This would be a bare minimum Eclipse installation.
Users could then install plugins they want within Eclipse itself.

Edit: Sry, I missed that there is already an eclipse-platform package in the aur, which could be used just for this purpose.
Comment by Antonio Rojas (arojas) - Tuesday, 07 April 2020, 07:19 GMT
Someone is working on this, reopening so they can post patches here
Comment by Carson Black (appadeia) - Tuesday, 07 April 2020, 14:01 GMT
This patchfile should do the necessary changes to get multiple versions of Eclipse working side-by-side.
Comment by Antonio Rojas (arojas) - Wednesday, 08 April 2020, 08:56 GMT
Thanks for the patch. Unfortunately it doesn't work here:

!SESSION 2020-04-08 10:51:39.270 -----------------------------------------------
java.vendor=Oracle Corporation
BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=es_ES
Command-line arguments: -os linux -ws gtk -arch x86_64

!ENTRY org.eclipse.osgi 4 0 2020-04-08 10:51:39.617
!MESSAGE Application error
java.lang.IllegalStateException: Unable to acquire application service. Ensure that the org.eclipse.core.runtime bundle is resolved and started (see config.ini).
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(
at sun.reflect.DelegatingMethodAccessorImpl.invoke(
at java.lang.reflect.Method.invoke(
at org.eclipse.equinox.launcher.Main.invokeFramework(
at org.eclipse.equinox.launcher.Main.basicRun(
at org.eclipse.equinox.launcher.Main.main(
Comment by Carson Black (appadeia) - Monday, 13 April 2020, 02:57 GMT
Whoops, invoked the correct binary in the wrong location.

The attached patch should work as expected.

The patch will require manual intervention when updating from users, as Eclipse will read from a variant-specific directory for config and data instead of from the generic directories it would have been reading beforehand, btw.