On 8/6/07, Mark Hindess <[EMAIL PROTECTED]> 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 > README/LICENSE/etc.)
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-1.6.0.00 /usr/lib/jvm/java-6-sun-1.6.0.00 (JDK_HOME) /usr/lib/jvm/java-6-sun-1.6.0.00/jre (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. > > >
