I'll very happy to see that the works done on my jakarta/xml RPM used more
heavily
on Apache projects (at least on Linux/Unix boxes).
So I propose that the sources and binaries RPMs I've done for
jakarta.apache.org and
xml.apache.org projects and which live now at ftp://ftp.falsehope.com to be
mirrored
at apache site at each release near the bin & src subdirs.
---
>From my RPM packager experience,
Even if Tomcat 4.0 is not the simplest project to rebuild, I've switched
from M4 to M5 very easily. I've only add to do minor modification to the
spec file (the file used to rebuild the binary RPM from source).
It's a situation where the RPM concept show its strength. You specify in the
spec file dependencies for building and running time.
Some rules I follow when building them...
* I try to build a RPM for all packages required by tomcat (ex: xerces-j,
regexp) from
source. When I didn't have access to source code, I still could build a
RPM.
In this case the binary RPM will only install all or parts of the binary
file to
specifics destinations (/usr/share/java/ /home/httpd/html/manual or
/var/www/html/manual)
* Big packages like tomcat goes in /var/ => /var/tomcat/ and /var/tomcat4/
since they also
include works directories. Next generations of RPM will follow the
standard Linux way in
splitting like this :
config goes in /etc/ => /etc/tomcat/
libraries goes in /var/ => /var/tomcat/lib/
logs goes in /var/log/ => /var/log/tomcat/
datas goes in /var/www/ => /var/www/webapps/
* Packages which could be seen like standard libraries, are installed in
/usr/share/java/ (ex: xerces.jar, xalan.jar, jakarta-regexp.jar...).
* Some jakarta packages like oro and regexp insert the version number in the
jar
name (ie: jakarta-regexp-1.1.jar). Something not very nice when you
upgrade from
1.1 to 1.2 and have some dependencies on outdated name. In the RPM, I use
symlink
to map to standard name
(ln -s /usr/share/java/jakarta-regexp-1.1.jar
/usr/share/java/jakarta-regexp.jar)
This layout (recommanded by Debian gurus) make easy the rebuilding via ant
or make,
since you know where the required jars must be found. (And if the project
require a
new package, you could expect to see a RPM for it.
The main problem here is about packages which must be downloaded from site,
like http://java.sun.com/products/. This is a real problem since even if we
could
generate binary RPMS for jsse or jmx, we couldn't distribute them.
* The best solution could be Sun to make them available to apache like they
do for jaxp
or servlet/jsp API. Even crypto laws are much more relaxed now.
* Another solution could be Sun supporting the RPM format ;-) I hope that
Craig and others
Apache commiters which works at Sun could do some lobbying in this area. I
could
even provide the revelant spec files for JSSE and JMX
* Another solution could be that Sun allow you to build a
tomcat4-tools.tar.gz including many
of the required packages and allow us to include it in RPM (not as a
separate module)
A RPM build is a reproductible stage. From source to binary you know
what you need and what you'll get.
When I try to build tomcat4 from my developpment system to a newly
installed, compilation not even start before I've installed ant and
regexp RPM.
It will help reduce the question on this list (and others) about missing .so
files
and how to configure a basic system. A well done RPM must do that kind of
job.
If it couldn't, it will fire a message at install time and indicate the user
what to do)
