tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GOMEZ Henri <hgo...@slib.fr>
Subject RE: Tomcat 4.0 RPMs?
Date Fri, 28 Sep 2001 16:45:33 GMT


-
Henri Gomez                 ___[_]____
EMAIL : hgomez@slib.fr        (. .)                     
PGP KEY : 697ECEDD    ...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 



>-----Original Message-----
>From: Christopher Cain [mailto:ccain@mhsoftware.com]
>Sent: Friday, September 28, 2001 6:15 PM
>To: Nicolas Mailhot
>Cc: tomcat-dev@jakarta.apache.org
>Subject: Re: Tomcat 4.0 RPMs?
>
>
>The problem is that we don't have the luxury of packaging the various 
>jars separately (most of them, anyway). This is essentially a case of 
>Licensing vs. Packaging. The "value add" clause of several jar 
>licenses, 
>unfortunately, state that we either bundle them in a single 
>package, or 
>we don't distribute them at all. The packaging policy of RPM 
>states that 
>we should not include them in the package. As you can see, those two 
>statements are mutually exclusive :)
>
>FWIW, I agree with you. The whole point of modular development and 
>deployment is that I should be able to manage my various components 
>separately. But since we don't have the legal ability to package the 
>various jars separately, and as Craig pointed out, that leaves us with 
>basically two options on RPMs:
>
>1) Make an RPM of Tomcat + everything that we can legally put in there.
>
>2) Make an RPM of Tomcat only, then require the user to separately 
>download each and every dependency jar.
>
>Having an RPM that just contains Tomcat may make version management of 
>the core TC product a little more convenient, but requiring users to 
>download and install numerous (non-RPM-availble) jars before they can 
>even run what was installed by our RPM ... that's a rather egregious 
>violation of what package management is all about.
>
>Under the circumstances, it is functionally impossible to offer the 
>version management benefits of RPM with TC4, because many of the 
>components that it requires are not themselves available as RPMs. The 
>only value of even having a TC4 RPM available, then, is simply as a 
>quick and painless "installer" for Linux. That's why I changed 
>my mind, 
>even though such an RPM offends my basic sensibilities (for all of the 
>reasons that you point out =)
>
>---------
>
>Nicolas Mailhot wrote:
>
>As a tomcat end *user*, I can tell you it's much *much* MUCH
>*MUCH* easier to track licence problems & jar versions by
>having 1 package per jar/source/licence.
>
>Having one package containing everything packed together is
>my nightmare. Having to dissect it to know where all the
>little bits come from and what is their individual license
>is much worse than having five or six packages, each with
>provider, version and license clearly listed in the rpm
>header (and that all the associated tools can easilly
>extract and sort)
>
>I do realise that with « dumb » packaging such as tars one
>single archive might be a better solution. But with modern
>packaging systems this defeats all the built-in enhancements
>that made end user life easier.
>
>Please do not ignore what Henry Gomez says. It's packaging
>policies are based on lots of packaging experience and
>end-user input (mine included:). All the problems that seem
>to bother you (copying jars in the right place,
>dependencies) are solved by rpm native functions and won't
>bother the end-user at all.
>
>- Christopher
>
>/**
>  * Pleurez, pleurez, mes yeux, et fondez vous en eau!
>  * La moitié de ma vie a mis l'autre au tombeau.
>  *    ---Corneille
>  */
>

Mime
View raw message