Bug 439825 - eclipse-ecj incompatible with JPackage 1.7 ecj
eclipse-ecj incompatible with JPackage 1.7 ecj
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: eclipse (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Andrew Overholt
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-31 12:14 EDT by David Walluck
Modified: 2008-04-11 19:59 EDT (History)
2 users (show)

See Also:
Fixed In Version: 3.3.2-2
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-11 19:59:17 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
relevant sections of 3.3.2, etc. patch (2.12 KB, patch)
2008-04-03 12:01 EDT, Andrew Overholt
no flags Details | Diff

  None (edit)
Description David Walluck 2008-03-31 12:14:26 EDT
This is related to bug #245054.

The eclipse-ecj package in Fedora is incompatible with JPackage 1.7 ecj. This
causes compatibility problems as well as (unnecessary) changes when porting
between JPackage and Fedora

Compatibility can be achieved by adding the correct Provides and symlinks to the
eclipse-ecj package.

1.) Add

Obsoletes: ecj < %{version}-%{release}
Provides: ecj = %{version}-%{release}

2.) Create the symlinks

%{_javadir}/ecj-%{version}.jar
%{_javadir}/ecj.jar

3.) The files %{_javadir}/eclipse-ecj.jar and %{_javadir}/jdtcore.jar currently
don't have versioned symlinks. I don't see any harm in adding them. The worst
that could happen is that they are unused.
Comment 1 Andrew Overholt 2008-03-31 13:47:46 EDT
I think the original reason this was done was because ecj and eclipse-ecj are
built from different sources and we can't guarantee that they'll be providing
the exact same bits.  Is this no longer the case?

Either way, I'd be happy to apply a patch.  I'll see if I can find a second to
whip something up if there isn't one in existence.

I can't do anything about RHEL-5 (but #245054).
Comment 2 David Walluck 2008-03-31 14:00:09 EDT
So we can't assume that ecj from eclipse 3.3.1.1 is the same as ecj 3.3.1.1? The
other way to solve it is to build ecj from the standalone sources as I believe
it is done in Mandriva and Ubuntu already, but I don't really see this as a big
issue.
Comment 3 Andrew Overholt 2008-03-31 14:09:07 EDT
(In reply to comment #2)
> So we can't assume that ecj from eclipse 3.3.1.1 is the same as ecj 3.3.1.1?

I've never seen the build procedure for the standalone case.  They could be
generating the same jar, but I haven't looked at it.

> The other way to solve it is to build ecj from the standalone sources as I 
> believe it is done in Mandriva and Ubuntu already, but I don't really see 
> this as a big issue.

Is there an advantage?  I've always thought of jdtcore as being _part_ of the
JDT and thus splitting it into a separate package just to be built again as part
of the SDK didn't seem right.
Comment 4 David Walluck 2008-03-31 15:29:46 EDT
It allows you to have a more-or-less standalone Java compiler (without pulling
in all of eclipse and its dependencies).
Comment 5 Andrew Overholt 2008-03-31 16:06:38 EDT
I think this was the initial motivation for the ecj package and for only
Obsoleting/Providing <= 2.1 (or whatever it is).  We figured if people wanted a
separate ecj package that they could build it as JPackage does and that it would
be independent of the JDT.
Comment 6 Jason Corley 2008-04-02 14:59:31 EDT
The jpackage version of ecj uses the full eclipse sources with all the non-ecj
stuff deleted so that it uses the same ant files as the full build would use. 
We created a custom tarball (with the script inside it which I believe is the
fedora policy) because the standalone sources did not include ant build files
(for some reason which I was unable to discern).

http://www.jpackage.org/cgi-bin/viewvc.cgi/rpms/free/ecj/ecj.spec?revision=1.1.2.4&root=jpackage&view=markup&pathrev=JPACKAGE-1_7
Comment 7 Andrew Overholt 2008-04-02 15:16:58 EDT
Okay, thanks for the clarification that they're built from the same sources.  I
think the only-obsoleting-less-than-2.1 thing can go away.  The symlinking is
fine by me, too.

Anyone have a patch?  If I can find time, I'll do it.
Comment 8 Andrew Overholt 2008-04-03 12:01:52 EDT
Created attachment 300274 [details]
relevant sections of 3.3.2, etc. patch

I just updated to 3.3.2 (something I should have done a month ago) and did this
at the same time.  Please let me know if the attached patch seems like it'll
break something or won't achieve the compatibility.  I've got a rawhide
(what'll become Fedora 9) build going now so we can test with those binary RPMs
when the build finishes.  You can watch for the build to finish and show up
here:

http://koji.fedoraproject.org/koji/packageinfo?packageID=183
Comment 9 David Walluck 2008-04-03 12:12:27 EDT
I think it looks OK, but what is/was the point of adding Provides: ecj <= (as
opposed to =)? So, if something wants ecj = 2.1, this would satisfy it? Does
that make sense?
Comment 10 Andrew Overholt 2008-04-03 12:33:54 EDT
(In reply to comment #9)
> I think it looks OK, but what is/was the point of adding Provides: ecj <= (as
> opposed to =)? So, if something wants ecj = 2.1, this would satisfy it? Does
> that make sense?

I don't know why the original <= was there.  I think maybe to get some older ecj
package to be removed when this was installed.  Do you think I should just make
it = ?
Comment 11 David Walluck 2008-04-03 13:32:14 EDT
I think it should be

Obsoletes: ecj < %{version}-%{release}
Provides: ecj = %{version}-%{release}

but I am not sure what the use of <= is.
Comment 12 Andrew Overholt 2008-04-03 14:38:05 EDT
Changed to =, killed build, re-started build.

Comment 13 David Walluck 2008-04-11 19:59:17 EDT
Fixed in 3.3.2-2.

Note You need to log in before you can comment on or make changes to this bug.