tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GOMEZ Henri <>
Subject RE: TC 4.0 RPM Packaging - WAS: [ANNOUNCEMENT] Apache Tomcat 4.0 Fina l Release
Date Mon, 24 Sep 2001 23:21:36 GMT
>Although there's no technical challenge to doing this, the licensing
>permission becomes much more murky.  The standard "permission to
>redistribute" paragraph on the other JAR files talks about packaging
>inside something with which you are adding value -- and it's 
>not obvious
>that your proposed approach would qualify, where it's pretty 
>obvious that
>the value add in the single-download approach is a complete application
>that includes functionality requiring those JARs.

The whole problem is there is just too many non OSS 
packages in TC 4.0 and that brake RPM policies.

And we're speaking about packaging an Apache Product, 
not a M$ tool and people used to see Apache 110% OSS.

>In general, though, how would making two RPMs rather than one 
>satisfy the
>"RPM packing requirements" rules any better?  If the JARs are 
>not supposed
>to be packaged in the primary RPM, why is having them in a separate RPM

We were speaking about the possibility to have the required jars 
outside TC 4.0 in an unique tarball which could be used in primary
TC 4.0 RPM or build into a second.

Having a second RPM, will clearly indicate to users that this stuff IS 
MANDATORY and a PRE-REQUISITE to build or use TC 4.0

>Personally, I'd lean a little further on the side of the poor 
>user whom we
>force to go through incredible machinations to install and use a binary
>distribution ...

That's why some people works on packaging, allowing poor users to
have just to type rpm -Uvh tomcat-xxx.noarch.rpm and have all the
stuff magically installed and working.

Personally, I'd like to see a more modular approach of TC 4.0 build,
allowing a diet TC 4.0 without any requirements on non OSS software.

If JSSE is still required for native HTTP/SSL in TC 3.2/3.3/4.0 
but users could still Apache + mod_ssl + mod_jk/webapp to have a 
100% OSS SSL solutions and that one could be dropped.

BTW, till we find a solution to the externals jars problems, 
having for example a tomcat-4.0-supplimental.tar.gz located 
at, we'll have to wait for the RPM.

I'm sure you could find a Sun Layer which will find an 
acceptable solution ;)

View raw message