As someone who deploys a lot of tomcat/mod_jk instances, I agree 100%. Certain things are better off non-RPM'd for easier up/down/crossgrades, and the java tools (jdk, ant, tomcat, etc) are great examples.

-te

Francois Caen wrote:

On Mon, 14 Feb 2005 17:49:27 -0500, UnIData unidata.linux@gmail.com wrote:

...

Where i can download tomcat in rpm format (latest version) ?

I found thru a lot of trial and error that you're better off using tomcat from a tarball. I hate using non-rpm software on my rpm-based systems but really, it's much better that way for tomcat.

Francois _______________________________________________ CentOS mailing list CentOS@caosity.org http://lists.caosity.org/mailman/listinfo/centos

Gotta disagree with you Troy....

A well managed system is one that is all RPMed...

Nothing worse than application code splattered over a file system (what's that... you installed to /usr instead of /usr/local/app or /opt/app).

Particularly when you have 100 odd servers... and you only spend a few hours a month on each....

I do believe this is why we have: http://www.jpackage.org/

:)

Peace to all....

Cheers,

Matt.

On Tue, 15 Feb 2005 10:04:38 -0500, Jim Bartus jbartus@advance.net wrote:

Troy Engel wrote:

...

As someone who deploys a lot of tomcat/mod_jk instances, I agree 100%. Certain things are better off non-RPM'd for easier up/down/crossgrades, and the java tools (jdk, ant, tomcat, etc) are great examples.

-te

I would take a listing of all the perl packages you have....

Then remove perl (and any other required packages). You can reinstall them later. :)

Solve the dependancies first.... once you put back the correct ones you'll be much better off.

Good luck!

Cheers,

Matt.

On Tue, 15 Feb 2005 09:31:17 -0600, Melinda Odom info@designhosting.biz wrote:

Hi,

I am on CentOS using Plesk as an administration area and am running into constant errors trying to update any perl packages because of an accidental install of a perl package from a third-party.

When I tried yum remove perl it listed every perl package on my system to remove which is what I do not want. I only want to remove one called perl-5.8.5-9rhel3.art

Below says "success" but those perl packages are not updated.

How can I just remove this one package, perl-5.8.5-9rhel3.art, so the other conflict errors will go away and not break the whole system? These are the errors:

[root@godslove root]# yum list updates Gathering header information file(s) from server(s) Server: CentOS-3 - Addons Server: CentOS-3 - Base Server: CentOS-3 - Extras Server: CentOS-3 - Updates Finding updated packages Downloading needed headers Name Arch Version Repo

---

---

perl-CGI i386 2:2.81-89.10 update perl-DB_File i386 2:1.804-89.10 update

[root@godslove root]# yum update perl Gathering header information file(s) from server(s) Server: CentOS-3 - Addons Server: CentOS-3 - Base Server: CentOS-3 - Extras Server: CentOS-3 - Updates Finding updated packages Downloading needed headers perl is installed and the latest version. No actions to take [root@godslove root]# yum update perl-CGI Gathering header information file(s) from server(s) Server: CentOS-3 - Addons Server: CentOS-3 - Base Server: CentOS-3 - Extras Server: CentOS-3 - Updates Finding updated packages Downloading needed headers Resolving dependencies Dependencies resolved I will do the following: [update: perl-CGI 2:2.81-89.10.i386] Is this ok [y/N]: y Downloading Packages Getting perl-CGI-2.81-89.10.i386.rpm perl-CGI-2.81-89.10.i386. 100% |=========================| 185 kB 00:00 Running test transaction: Test transaction complete, Success! Errors installing: ('file /usr/share/man/man3/CGI.3pm.gz from install of perl-CGI-2.81-89.10 confli cts with file from package perl-5.8.5-9.rhel3.art', (7, '/usr/share/man/man3/CGI .3pm.gz', 0L)) ('file /usr/share/man/man3/CGI::Apache.3pm.gz from install of perl-CGI-2.81-89.1 0 conflicts with file from package perl-5.8.5-9.rhel3.art', (7, '/usr/share/man/ man3/CGI::Apache.3pm.gz', 0L)) ('file /usr/share/man/man3/CGI::Carp.3pm.gz from install of perl-CGI-2.81-89.10 conflicts with file from package perl-5.8.5-9.rhel3.art', (7, '/usr/share/man/ma n3/CGI::Carp.3pm.gz', 0L)) ('file /usr/share/man/man3/CGI::Cookie.3pm.gz from install of perl-CGI-2.81-89.1 0 conflicts with file from package perl-5.8.5-9.rhel3.art', (7, '/usr/share/man/ man3/CGI::Cookie.3pm.gz', 0L)) ('file /usr/share/man/man3/CGI::Fast.3pm.gz from install of perl-CGI-2.81-89.10 conflicts with file from package perl-5.8.5-9.rhel3.art', (7, '/usr/share/man/ma n3/CGI::Fast.3pm.gz', 0L)) ('file /usr/share/man/man3/CGI::Pretty.3pm.gz from install of perl-CGI-2.81-89.1 0 conflicts with file from package perl-5.8.5-9.rhel3.art', (7, '/usr/share/man/ man3/CGI::Pretty.3pm.gz', 0L)) ('file /usr/share/man/man3/CGI::Push.3pm.gz from install of perl-CGI-2.81-89.10 conflicts with file from package perl-5.8.5-9.rhel3.art', (7, '/usr/share/man/ma n3/CGI::Push.3pm.gz', 0L)) ('file /usr/share/man/man3/CGI::Switch.3pm.gz from install of perl-CGI-2.81-89.1 0 conflicts with file from package perl-5.8.5-9.rhel3.art', (7, '/usr/share/man/ man3/CGI::Switch.3pm.gz', 0L)) ('file /usr/share/man/man3/CGI::Util.3pm.gz from install of perl-CGI-2.81-89.10 conflicts with file from package perl-5.8.5-9.rhel3.art', (7, '/usr/share/man/ma n3/CGI::Util.3pm.gz', 0L))

==========================================================

[root@godslove root]# yum update perl-DB_File Gathering header information file(s) from server(s) Server: CentOS-3 - Addons Server: CentOS-3 - Base Server: CentOS-3 - Extras Server: CentOS-3 - Updates Finding updated packages Downloading needed headers Resolving dependencies Dependencies resolved I will do the following: [update: perl-DB_File 2:1.804-89.10.i386] Is this ok [y/N]: y Downloading Packages Getting perl-DB_File-1.804-89.10.i386.rpm perl-DB_File-1.804-89.10. 100% |=========================| 72 kB 00:00 Running test transaction: Test transaction complete, Success! Errors installing: ('file /usr/share/man/man3/DB_File.3pm.gz from install of perl-DB_File-1.804-89.10 conflicts with file from package perl-5.8.5-9.rhel3.art', (7, '/usr/share/man/man3/DB_File.3pm.gz', 0L))

Sincerely, Melinda Odom www.designhosting.biz 479-471-0891 -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.300 / Virus Database: 265.8.8 - Release Date: 2/14/2005

---

CentOS mailing list CentOS@caosity.org http://lists.caosity.org/mailman/listinfo/centos

Hi Matt,

We'll agree to disagree. :) Tomcat and java are sometimes a little iffy from version to version, since you're dealing with a lot of seperate jarballs from different places (ie mysql connectors, axis, struts, xalan/xerces, etc) and there are a number of times when you need to do a lot of independant things outside of an RPM construct, upgrading and downgrading to get around bugs or apply a performance enhancement.

It's all about good design, which can overcome any "splatterings" (man do I hear you there! ugh) all over the filesystem. By the rigid use of symlinks, proper ant build scripts (ie to deploy new jarballs of, say, Axis into tomcat's home) and a full understanding of how to use tomcat (ie keeping server.xml in CVS, using -config to grab it) and mod_jk you can actually have a much more powerful setup than an RPM that "someone else" designed for you.

It also makes for testing/deploying new tomcats (sic) and downgrading in an emergency a real piece of cake, something that you can't do in 11 seconds with an RPM version. Ie:

/opt/jakarta-tomcat-5.5.4/ /opt/jakarta-tomcat-5.5.7/ /opt/tomcat -> /opt/jakarta-tomcat-5.5.7

There have been numerous times where issues burried deep down inside tomcat have only surfaced in production scenarious, no matter how much testing we do on the development servers. (That good old fashioned random user input is what it takes to find them. :)) Dropping back a tomcat version is slick, fast, and easy when you're symlinking.

Anyone who's ever spent time at the systems level trying to debug some completely obscure java memory leak or improper use of a synchronized class in a mutlithreaded situation will know my pain.

-te

Matt Bottrell wrote:

Gotta disagree with you Troy....

A well managed system is one that is all RPMed...

Nothing worse than application code splattered over a file system (what's that... you installed to /usr instead of /usr/local/app or /opt/app).

Particularly when you have 100 odd servers... and you only spend a few hours a month on each....

I do believe this is why we have: http://www.jpackage.org/

:)

Peace to all....

Cheers,

Matt.

On Tue, 15 Feb 2005 10:04:38 -0500, Jim Bartus jbartus@advance.net wrote:

...

Troy Engel wrote:

...

As someone who deploys a lot of tomcat/mod_jk instances, I agree 100%. Certain things are better off non-RPM'd for easier up/down/crossgrades, and the java tools (jdk, ant, tomcat, etc) are great examples.

-te

---

CentOS mailing list CentOS@caosity.org http://lists.caosity.org/mailman/listinfo/centos

On Tue, 2005-02-15 at 17:11, John Newbigin wrote:

Jim Bartus wrote:

...

Y'ever try the "Red Hat Application Server" (tomcat + jonas)? http://www.redhat.com/software/rha/appserver/

RHAS is available free but I think it is out of date. It seems that Red Hat(R) are contributing to jpackage and I would think that future versions of RHAS will just be jpackage on a CD. (JPackage could be the Fedora of the java world).

I am still looking for the best way to run eclipse on CentOS-3 with sun java. It sounds like a simple task...

any news about whether they'll provide an open-source IDE, probably based on Netbeans 4.1, that supports development of EJBs?

-- TT