harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nathan Beyer" <nbe...@gmail.com>
Subject Re: [packaging] Debian packaging
Date Mon, 06 Aug 2007 23:09:23 GMT
On 8/6/07, Mark Hindess <mark.hindess@googlemail.com> wrote:
> I've tried to create some Debian packages at:
>   http://people.apache.org/~hindessm/debian/
> (And I've created a debian subdirectory in the federation build tree.)
> At the moment, they are binary only.  This is because Debian source
> packaging tools expect a "distclean" target that leaves the build tree
> in pristine condition - i.e. without new files in depends/jars, vm/
> build/pre-copied, etc.
> Currently the jdk package contains the jre so the jdk and jre
> packages are configured to conflict with one another so that they
> aren't both installed at the same time.  It might be better to
> package the jre to install to /usr/lib/apache-harmony/jre and then to
> have the jdk depend on the jre and install the additional files to
> /usr/lib/apache-harmony/{bin,lib,include}.  This feels slightly more
> natural way to define the packages but I'd be interested in what others
> think about it?  (We might end up duplicating a few text files like

This may be just an Ubuntu (Fiesty Fawn) thing, but I think the way
Sun's JDK and JRE are laid out is logical.

/usr/lib/jvm/java-6-sun -> /usr/lib/jvm/java-6-sun-
/usr/lib/jvm/java-6-sun- (JDK_HOME)
/usr/lib/jvm/java-6-sun- (JRE_HOME)

Then there's a /etc/alternatives/XXX item for all the relevant
executables in the "JDK_HOME/bin" and "JRE_HOME/bin" folders. There
are also symbolic links for these alternatives items in the /usr/bin
folder. The Java 5 packages do the same.

I'd suggest that we follow this layout and do something like this.

/usr/lib/jvm/java-5-apache-harmony -> /usr/lib/jvm/java-5-apache-harmony-5.0.M2
/usr/lib/jvm/java-5-apache-harmony-5.0.M2 (JDK_HOME)
/usr/lib/jvm/java-5-apache-harmony-5.0.M2/jre (JRE_HOME)

> Duplication of dependencies that are already packaged for Debian is
> strongly discouraged.  It would be better to use the already packaged
> version of xerces, xalan, zlib, libpng, etc.  It would also be better to
> use shared libraries not static libraries.  (Including [non-PIC] static
> libraries like libpng.a inside libpngencoder.so would definitely be
> frowned upon.)
> I think our handling of dependencies is an area that is overdue for a
> re-think.  I'll start a new thread about this.
> Regards,
>  Mark.

View raw message