On Fri, Apr 26, 2002, Garrett Conaty wrote:
> I'd like to start a discussion on building Java RPMs for OpenPKG.
> Specifically, I need to create RPMs for the jakarta tools.
Yes, for our customers at C&W we also need such stuff from time to time
and would be happy to have them as OpenPKG packages, too.
> The two
> models to go from are the jakarta-originated RPMS and a tomcat RPM. (If
> anyone has pointers to how other people are building Java RPMs I'd love
> to hear about them.)
We certainly can get hints from those RPMS. But be very carefully:
experience showed that it is better to write an OpenPKG .spec from
scratch and only "steal" hints from existing ones instead of trying
to rewrite existing .spec's into the format of OpenPKG. The reason is
that OpenPKG .spec files are a lot more concise than other .spec files
(because of shtool, rpmtool and %{l_xxx} features). So, in order to get
a clean solution, I recommend to start from scratch and only take over
selected pieces.
> Essentially, building something like tomcat is a dependency hell, but
> definitely solvable using the features of RPM.
Yes, they usually require at least JDK and Ant. For JDK we have
a package, for Ant a package usually first has to be built, too.
> The challenge is that
> the docs can be somewhat outdated for what various Java JARs are needed
> and/or which version of the JDK provides them (e.g. JNDI comes with
> JDK1.4, but the tomcat instructions say to download the JNDI
> implementation).
Exactly, the Java folks usually have very bad installation documents
and do not use any "de facto standard" like the Autoconf "configure"
interface. For Tomcat in the past we found only very outdated docs. I
hope it is now better with Tomcat 4.
> What I'd really like to discuss is the installation location of these
> files. If a JAR can be likened to a shared library, then doesn't it
> make sense to have an equivalent 'lib' directory for these? Some
> package creators dump JAR files under %{prefix}/share/java, which,
> though platform neutral (and hence under 'share') are still libraries.
You mean that we end up in multiple packages, each provide lots of
.jar files and they use them in a shared way so it could make sense
to provide them all in a single top-level directory? Hmmm... because
they are similar to .a and .so files, I see no problem is putting them
directly into %{l_prefix}/lib, because they do not conflict with .a and
.so files.
> OpenPKG takes a different approach (with tomcat anyway) by putting stuff
> under %{l_prefix}/libexec/tomcat. Which is better?
The libexec approach is the standard one if a package is such nasty as
Tomcat. But we did it this way mainly because it was the easiest way to
force Tomcat into our filesystem hierarchy. But if someone investigates
it would be nice if we end up in a "tomcat" package which
1. builds from scratch (and is not based on pre-built bytecode packages)
2. is split directly into the install dirs %{l_prefix}/{bin,lib,share/tomcat}
Feel free to do this.
> I certainly like
> devoting packages to their own directory structure, but this quickly
> becomes unwieldly for library dependencies, hence the inevitability of a
> /lib directory.
> I think it could be rationalized to treat Java packages like traditional
> GNU packages; putting stuff into /bin, /etc, /lib, and so forth.
Exactly. Go for this... but make sure that into /lib really only .jar
files are stored. Not any other stuff which the Java folks usually like
to clutter of the filesystem.
> Of course we could have /lib/java, but that would seem to be reserved
> for libraries just for the JDK (though, they're totally separate). And
> then tools like Perl do things totally different as well, with perl
> modules under a separate Perl tree.
Hmmm... "perl" uses %{l_prefix}/lib/perl5, so it could be reasonable
to put Java stuff under %{l_prefix}/lib/java. I personally have
no objection against this, too. Both %{l_prefix}/lib/foo.jar and
%{l_prefix}/lib/java/foo.jar are fine. Perhaps we should start with
%{l_prefix}/lib/java/ and if this works through out all Java packages we
easily can remove this sub-directory later. But adding it is certainly
harder.
> In any case, I'm leaning towards the /bin,/etc,/lib structure, but the
> openpkg tomcat RPM is set up differently, and I thought I'd canvass the
> OpenPKG developers.
Do not bother about the "tomcat" package. We are not very happy
about its structure ourself. So if we end up in a from-scratch
implementation of this package we certainly do not object.
So, as I see it, the best approach seems to be:
1. create a better "jdk" package: for JDK 1.4 and preferrable
buildable from source with the binary JDK only for bootstrapping.
2. create an "ant" package (requiring "jdk") because it is needed
later for packages like "tomcat", "fop", etc.
3. create a better "tomcat" package (requiring "jdk" and "ant"): for
Tomcat 4 and preferrable buildable from source.
If we could achieve this, I think this would be a great step forward in
Java support inside OpenPKG.
Ralf S. Engelschall
[EMAIL PROTECTED]
www.engelschall.com
______________________________________________________________________
The OpenPKG Project www.openpkg.org
Developer Communication List [EMAIL PROTECTED]
