On Tue, Jun 16, 2009 at 2:56 PM, Jens Kapitza<webmas...@schwarze-allianz.de> wrote: > >> I can help to package some of the deps if needed. > > I can offer my time if some can tell me how i can help. > Which bugs should be fixed first? > Is there some kind of roadmap? > Well a "rough" roadmap would go like this:
1) Package dependencies, push to main (Skills: Java, packaging) 2) Integrate the eclipse-build system from upstream Eclipse Linux Tools Project once it is released. Perhaps help so that it can be released sooner. (Skills: Java, Ant/XML, OSGi, P2) 3) Figure out a filesystem layout for plug-ins. An idea could be to do as Fedora does and use e.g., /usr/share/eclipse/<plugin_name> (thus staying out of P2's way) or figure out how to integrate apt with P2 (this will need development of a debian/apt specific "touchpoint" in P2-speak, at least as I understand it. (Skills: Understanding of Debian Policy) 4) Figure out how to divide eclipse properly into binary packages. E.g., should we package OSGi runtime separately or not? (some people actually use it standalone). There is also swt which I think is already packaged separately since it powers some non-eclipse applications. (Skills: Understanding of Debian Policy) 5) Figure out what to do with eclipse's native libraries. We will most likely follow the fedora way here and use the little helper equinox app that "unpacks" them from their jars so that they can be placed in /usr/lib and be easier to patch for security issues etc. (Skills: Understanding of Debian Policy, OSGi/equinox) 6) Figure out how to arrange installed eclipse in the filesystem. Especially what goes under /usr/lib and what under /usr/share. Things are little tricky here (e.g., some architecture-indep stuff may still end up under /usr/lib for convenience). (Skills: Understanding of Debian Policy) 7) Integrate all the above, push to debian. Profit. There is no point to bother with any release prior to 3.5.0 since so much stuff has changed that it will be a loss of (valuable) volunteer time imho. P.S., In the meantime, the idea of an "installer-type" package that goes in contrib and just installs the upstream binary while taking care of the dependencies (particularly the xulrunner stuff that tends to cause most pain) would still be useful to users and an order of magnitude easier to accomplish. -- To UNSUBSCRIBE, email to debian-java-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
