tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <Craig.McClana...@eng.sun.com>
Subject Re: [VOTE] RPM packaging
Date Fri, 15 Dec 2000 17:12:14 GMT
GOMEZ Henri wrote:

> 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.
>

+1 ... and a *very* big thank you for all of Henri's work to make these
things!!!

See below for a couple of more comments.

>
> ---
>
> >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
>

Redistribution rights and packaging format are two different issues.  If we
(Apache folks) had redistribution rights, we could build the packages, in
whatever format we like, just like we do all the rest.

Now, on JMX we (Sun folks) might be able to have some influence.  On JSSE, I
would not hold your breath.  The federal crypto laws have indeed been relaxed,
but you're still required to prohibit downloads to a country on the restricted
list.

Do *you* want to have to do a click-through certifying where you are in order to
download a package?  Naw, I didn't think so.  So JSSE isn't going to be
feasible, even if Sun gave permission, without lobbying the feds.

>
> * 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)
>

The dilemma, of course, is the same as for the build scripts -- I, as a
developer, want to be able to pick and choose which versions of the dependent
packages are used on *my* development machine.

Nothing stops us, though, from doing this for all the packages that are already
redistributable -- just as nothing stops us from including those JAR files in
the binary distributions.

>
> 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)

Craig



Mime
View raw message