Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: tomcat-dev@jakarta.apache.org
Message-ID: <D84B43C5F94DD511877400609457497C5880EC@css4.cs>
From: GOMEZ Henri <hgomez@slib.fr>
To: tomcat-dev@jakarta.apache.org
Subject: RE: Tomcat 4.0 RPMs?
Date: Fri, 28 Sep 2001 18:45:33 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


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


>-----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=20
>jars separately (most of them, anyway). This is essentially a case of=20
>Licensing vs. Packaging. The "value add" clause of several jar=20
>licenses,=20
>unfortunately, state that we either bundle them in a single=20
>package, or=20
>we don't distribute them at all. The packaging policy of RPM=20
>states that=20
>we should not include them in the package. As you can see, those two=20
>statements are mutually exclusive :)
>
>FWIW, I agree with you. The whole point of modular development and=20
>deployment is that I should be able to manage my various components=20
>separately. But since we don't have the legal ability to package the=20
>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=20
>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=20
>download and install numerous (non-RPM-availble) jars before they can=20
>even run what was installed by our RPM ... that's a rather egregious=20
>violation of what package management is all about.
>
>Under the circumstances, it is functionally impossible to offer the=20
>version management benefits of RPM with TC4, because many of the=20
>components that it requires are not themselves available as RPMs. The=20
>only value of even having a TC4 RPM available, then, is simply as a=20
>quick and painless "installer" for Linux. That's why I changed=20
>my mind,=20
>even though such an RPM offends my basic sensibilities (for all of the =

>reasons that you point out =3D)
>
>---------
>
>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 =AB dumb =BB 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=E9 de ma vie a mis l'autre au tombeau.
>  *    ---Corneille
>  */
>