Re: Active Java packagers
On Tue, Jun 16, 2009 at 2:56 PM, Jens
Kapitza<webmaster@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.
Reply to: