[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: plans for eclipse luna in debian

Am 17.10.2015 um 15:02 schrieb Luca Vercelli:
> Dear Marckus,
> you were right. There is "a lot of work" in order to compile Eclipse Mars.
> I attach a preliminary version of required dependencies. I am trying to
> build Tycho before Eclipse, and I am still far away.

Hi Luca,

it always seems overwhelming at first, especially because Eclipse is one
of the most complex packages you will ever see, but you have already
taken an important step forward by compiling those dependency lists. The
next step is to split the work into smaller parts and to package
required dependencies.

Dependencies with different versions can be a problem but they don't
have to be. We use maven.rules to rewrite dependency versions, so
version 1.2.3 becomes 1.x or debian. Then again sometimes we have to
package a newer upstream release to satisfy the build-dependency.

Dependencies we don't have:

We have jetty and osgi-annotation. The atinject and glassfish
dependencies should be there too. Eclipse-license can probably be
ignored. We have to write our own debian/copyright file anyway.

In general it looks like we already ship most of the required
dependencies. It would be a big help, if you want to work on Tycho. I
will try to create an initial debian directory for Eclipse. If you
struggle with a dependency, just ignore it for now and add it to
maven.ignoreRules. After that the work flow looks like that:

1. Try to build the package (debuild -us -uc)
2. Package fails with error message: artifact xyz missing
3. Artifact already packaged for Debian?
   yes -> Add build-dependency to debian/control and add a new rule to
   maven.rules (not always required)

   no -> package dependency, remove it from maven.ignoreRules, add it
   to debian/control, write a new rule for maven.rules

4. Repeat step 1-3 until the package can be built from source.

The build can fail because of incompatible versions too. In this case we
should take a closer look and decide whether we have to package a newer
version or if we can write a patch to circumvent the issue. Whatever is
simpler for now. Thumb of rule is: Get a working package with the
minimum number of build-dependencies and optimize everything after the
whole thing compiles.



Attachment: signature.asc
Description: OpenPGP digital signature

Reply to: