Updating Eclipse

Sat Jan 10 12:02:18 UTC 2015

On 2015-01-09 20:21, Markus Koschany wrote:
> Hi Pascal,
>
> On 09.01.2015 19:43, Pascal Rapicault wrote:
>> Hi,
>>

Hi Pascal,

(NB: Please CC me explicit on replies as I am not subscribed to debian-java)

For reference, I am more than happy to provide advice and technical aid
where possible.  But I am not able to be a co-maintainer of eclipse.

>> My name is Pascal Rapicault. I'm a long time committer on the Eclipse
>> platform, and I've recently been tasked by Ericsson to:
>> 1 - bring new versions of Eclipse to debian
>> 2 - make sure the experience of using eclipse on debian is good (from an
>> installation pov)
>> 3 - make sure the user can get multiple versions of Eclipse installed at
>> the same time but not all merged (e.g. IDE for C/C++, IDE for Java, etc.)
>> 4 - find a way to streamline the push of Eclipse to debian
> 
> Thank your for your interest in Eclipse and the state of Java packages
> in Debian. [...]
> 

Indeed thanks for your interest.  And thanks to Ericsson as well. :)

>>> I recently worked on a mechanism that creates debian packages from an
>> eclipse distro as a single package (all the jars and other files are in
>> one package) and is also able to collect the dependencies on native
>> packages. This works quite well since it makes it easy for the users to
>> get a functional starting point (IDE for Java, IDE for C/C++) that they
>> can customize, and allows multiple IDEs to be installed separately.
>>
>> Now a couple questions:
>> - Would the package I describe above be suitable to be made available in
>> the main debian repo? (I assume no, but I may as well check :))

I strongly suspect the answer to be no as well.  Debian is not really
that much into "fat packages", static linking or the "strictly equals"
dependencies (outside binaries built from same source package).

>> - What are the reasons why Eclipse is no longer updated, technical,
>> political, volunteers?

I suspect mostly lacking volunteers willing to provide a debian package
under the "technical and political" requirements of Debian.

>> - What are the requirements to package Eclipse for debian?

I believe Markus already touched on some of these.  I only have an
incomplete list.  None that some of my remarks / follow comments here
are based on my time as Debian maintainer of eclipse (mostly active
during 2009-2011ish). Anyhow:

 * DFSG compatible licenses.  Here Eclipse general excels with its IP
   and rigid handling of copyright/licenses.
 * Rebuild things from source.  Some of it works, except for the
   bootstrap problem.  Namely to compile eclipse you (used to?) require
   eclipse.
 * No / Avoid bundling of libraries and avoid static linking.
 * Rebuild everything *without internet*.  Mostly an issue with maven.
   In my time, Eclipse did not have an issue here, but I heard they
   considered moving to maven or so?
 * Debian generally tries to avoid "= $version" dependencies, which are
   fairly common in the Java world (if I am not mistaken).
 * The package must be policy compliant[1].  That is a long read, so
   I would not start here.  For reference, the current eclipse package
   is mostly good enough.
   - I would recommend getting a working compile first and then worry
     about policy compliance afterwards.

>> - What are the most "painful" aspects of this process? 
> [...]

Again note that my remarks here are based from my experience and may
have changed since 2011.  Hopefully you will find it easier - your time
as Eclipse committer might make a lot of things easier for you.  Also
please note that some of these issues are not specific to Debian (e.g.
Fedora have similar concerns).

 * Eclipse upstream and Debian had different ideas on certain things
   like "how much should be rebuilt from source".
   - Debian: Everything *must* be rebuildable and everything *should* be
     be rebuilt during a package build.
   - Eclipse: Automatic rebuilds are /sometimes/ an afterthought or not
     done at all (e.g. because they "consume the official" binaries of
     XYZ).
 * Providing patches to Eclipse upstream was generally difficult.  I
   suspect you will it a lot easier here, being already integrated
   upstream.
   - My problems were mostly "I find a problem at X, where do I file a
     bug (i.e. which component maintains X)?"
   - During most of my involvement, I had to rely on others having time
     to commit my patches.  I did manage to become a committer at some
     point, but at that time I had mostly burned out.
 * The bootstrap problem.  To have compile eclipse version X, you
   generally need(ed?) eclipse X to pre-build some build files.
   - Some people from Fedora started an "eclipse-build" project[2] to
     solve the bootstrap problem and ease automatic building of eclipse
     (from scratch).
   - The bootstrap problem is/was solved by pre-compiling some build
     scripts, which were used to bootstrap enough of eclipse for it to
     generate build scripts.  Here after everything is rebuilt just to
     prove everything is buildable.  This is the (debian/)eclipse-build-
     generatedScripts.tar.bz2 file in the current Debian source
     package[3].
 * Debian was always playing "catch up" with Fedora.  This is not to
   say anything bad about Fedora or the people in the eclipse-build
   project.  I was grateful for their work, but it was frustrating to
   to always play catch-up.
   - Especially when lack of support is caused by something trivial like
     "bashisms" in a "sh" script[4] or Fedora and Debian having
     different locations for a jar file.
   - This is a vicious cycle as the de-motivation only caused us to
     become further behind... :)
 * Providing OSGi support for (non-eclipse) JAR files in other debian
   packages.
   - We spent a few month adding those back in 2009 and 2010.
     Hopefully most of it is still correct.  But it was a lot of work
     to migrate from eclipse 3.2 to 3.5.
 * When build breaks, it is sometimes painful to figure out what went
   wrong.  Especially when the upstream build does not fail on first
   error (but instead continues and explodes later or creates broken
   binaries/jar files).
 * It is difficult to get co-maintainers that pull their weight.  A lot
   of people are ready to say they will help.  But eclipse is so huge
   and complex that they do not know where to start.
   - So there may be a lot of offers, but very few of them ends up hangs
     around after a week or two (other than "in name").

Also: for better and for worse, Debian has separated swt from eclipse.
This means that the eclipse package actually compiles SWT, throws it
away and uses SWT from the swt-gtk (or swt4-gtk) package.  This was an
artefact of last time eclipse was not updated in a timely manner.

But in summary, have a look at the eclipse-build project[2].  This is
probably the best possible entry point to compiling a newer eclipse.
  It is definitely doable, but it required a larger commitment than I
was able to provide more than a couple of years (as a volunteer).

~Niels

PS: You will want a machine with sufficient RAM.  I suspect today's
average hardware have sufficient capacity, but it is the difference
between a 15 minutes and a 90 minutes build (and possibly your build or
desktop being OOM-killed).

[1] https://www.debian.org/doc/debian-policy/

[2] http://wiki.eclipse.org/Linux_Tools_Project/Eclipse_Build

[3] The debian/eclipse-build-generatedScripts.tar.bz2 variant was
because we needed a rebuilt after the one provided from eclipse-build
and I did not want to override a binary file in the "orig" tarball.

[4] Fedora uses /bin/bash as /bin/sh.  Debian migrated to /bin/dash, so
a lot of the "extra" features in bash are not present in our /bin/sh.
These bashism problems occur in many different places (even outside
eclipse-build).