Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: tomcat-dev@jakarta.apache.org
Message-ID: <D84B43C5F94DD511877400609457497C5880ED@css4.cs>
From: GOMEZ Henri <hgomez@slib.fr>
To: tomcat-dev@jakarta.apache.org
Cc: Nicolas Mailhot <Nicolas.Mailhot@one2team.com>, ccain@mhsoftware.com,
   Guillaume Rousse <rousse@ccr.jussieu.fr>
Subject: RE: Tomcat 4.0 RPMs?
Date: Fri, 28 Sep 2001 18:51:17 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Another solution will be to have in Source RPM,
tomcat 4.0 source AND tomcat 4.0 binary=20
where I could get the needed jar.

Will make a huge SOURCE RPM but will solve
the problem...

I'll remove the jaxp/crimson and require in
RPM jaxp/crimson or xerces and use the one=20
available.=20

tyrex will need a separate RPM since it's also
an independant functionnalitie and since the
source tarball include all the necessary jars
(jta for example) it will be easy....

But that RPM will be not really a 100% clean=20
one since it broke some RPM requirement like
having access to all the source.

Not very bad for an OSS project

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