On CentOS 5, why does 'yum remove tomcat*' remove all of the openoffice packages?
Les Mikesell wrote:
On CentOS 5, why does 'yum remove tomcat*' remove all of the openoffice packages?
That would be because openoffice requires tomcat to install it ... if you tell yum that you want to remove tomcat ... since openoffice requires tomcat, it has to also remove openoffice.
Johnny Hughes wrote:
Les Mikesell wrote:
On CentOS 5, why does 'yum remove tomcat*' remove all of the openoffice packages?
That would be because openoffice requires tomcat to install it ... if you tell yum that you want to remove tomcat ... since openoffice requires tomcat, it has to also remove openoffice.
It seems bizarre for an office suite to depend on a java servlet engine, but OK... Now how do I get one that works under Sun java? And is there a way to get eclipse without gcj?
Les Mikesell wrote:
Johnny Hughes wrote:
Les Mikesell wrote:
On CentOS 5, why does 'yum remove tomcat*' remove all of the openoffice packages?
That would be because openoffice requires tomcat to install it ... if you tell yum that you want to remove tomcat ... since openoffice requires tomcat, it has to also remove openoffice.
It seems bizarre for an office suite to depend on a java servlet engine, but OK...
We don't write it, we just build it and make sure it links up correctly compared to upstream.
Now how do I get one that works under Sun java? And is there
a way to get eclipse without gcj?
Not from Red Hat (wrt sun java) ... they did use tomcat and gcj. If you want sun java, I imagine you would have to change the specs and rebuild. I have no idea how to do that (I have not looked at it at all).
You COULD get the OOo2 suite from the openoffice.org website ... that gets rid of the tomcat issues.
Eclipse ... not sure.
Johnny Hughes wrote:
On CentOS 5, why does 'yum remove tomcat*' remove all of the openoffice packages?
That would be because openoffice requires tomcat to install it ... if you tell yum that you want to remove tomcat ... since openoffice requires tomcat, it has to also remove openoffice.
It seems bizarre for an office suite to depend on a java servlet engine, but OK...
We don't write it, we just build it and make sure it links up correctly compared to upstream.
Now how do I get one that works under Sun java? And is there
a way to get eclipse without gcj?
Not from Red Hat (wrt sun java) ... they did use tomcat and gcj. If you want sun java, I imagine you would have to change the specs and rebuild. I have no idea how to do that (I have not looked at it at all).
Red Hat fixed their bug: http://rhn.redhat.com/errata/RHBA-2007-0365.html I haven't seen a response to centos bugzilla 0002160 that I filed a month ago about this.
And they have a packaged Sun Java available http://rhn.redhat.com/errata/RHEA-2007-0223.html (that's the link for rhel4 but I think there is one for 5 too).
You COULD get the OOo2 suite from the openoffice.org website ... that gets rid of the tomcat issues.
Eclipse ... not sure.
In theory it shouldn't hurt to have the unused gjc package sitting around.
It seems bizarre for an office suite to depend on a java servlet engine, but OK...
You can remove some of the tomcat packages without removing openoffice
Populating transaction set with selected packages. Please wait. ---> Package tomcat5-webapps.x86_64 0:5.5.23-0jpp.1.0.4.el5 set to be erased ---> Package tomcat5-jasper.x86_64 0:5.5.23-0jpp.1.0.4.el5 set to be erased ---> Package tomcat5.x86_64 0:5.5.23-0jpp.1.0.4.el5 set to be erased ---> Package tomcat5-common-lib.x86_64 0:5.5.23-0jpp.1.0.4.el5 set to be erased --> Running transaction check --> Processing Dependency: tomcat5-jasper = 0:5.5.23-0jpp.1.0.4.el5 for package: tomcat5-server-lib --> Restarting Dependency Resolution with new changes. --> Populating transaction set with selected packages. Please wait. ---> Package tomcat5-server-lib.x86_64 0:5.5.23-0jpp.1.0.4.el5 set to be erased --> Running transaction check
BUT--->you can't remove the servlet or jsp api without removing openoffice and a host of others.
Les Mikesell wrote:
Johnny Hughes wrote:
On CentOS 5, why does 'yum remove tomcat*' remove all of the openoffice packages?
That would be because openoffice requires tomcat to install it ... if you tell yum that you want to remove tomcat ... since openoffice requires tomcat, it has to also remove openoffice.
It seems bizarre for an office suite to depend on a java servlet engine, but OK...
We don't write it, we just build it and make sure it links up correctly compared to upstream.
Now how do I get one that works under Sun java? And is there
a way to get eclipse without gcj?
Not from Red Hat (wrt sun java) ... they did use tomcat and gcj. If you want sun java, I imagine you would have to change the specs and rebuild. I have no idea how to do that (I have not looked at it at all).
Red Hat fixed their bug: http://rhn.redhat.com/errata/RHBA-2007-0365.html
That has been pushed to updates ... however, I don't see it has any impact on open office. It is related to tomcat.
I haven't seen a response to centos bugzilla 0002160 that I filed a month ago about this.
I didn't see the bug before ... but it was released 7/22/2007: redhat-rpm-config-8.0.45-17.0.1.el5.centos.noarch.rpm
<snip>
Johnny Hughes wrote:
Not from Red Hat (wrt sun java) ... they did use tomcat and gcj. If you want sun java, I imagine you would have to change the specs and rebuild. I have no idea how to do that (I have not looked at it at all).
Red Hat fixed their bug: http://rhn.redhat.com/errata/RHBA-2007-0365.html
That has been pushed to updates ... however, I don't see it has any impact on open office. It is related to tomcat.
I was trying to remove the non-working tomcat with the idea of replacing it with something else and openoffice went with it. Odd, but fixable.
I haven't seen a response to centos bugzilla 0002160 that I filed a month ago about this.
I didn't see the bug before ... but it was released 7/22/2007: redhat-rpm-config-8.0.45-17.0.1.el5.centos.noarch.rpm
Thanks, but I thought the bug was related to the way the way the java-containing rpms were built (or maybe installed..) and this rpm just fixes the process. What will it take to get working indexes into the jar files for tomcat (and probably other apps) on an existing system?
Also, is there any chance of duplicating those Red Hat sun jdk rpms? I think you've said no before, but I'm curious about how debian was able to manage it: http://packages.debian.org/unstable/source/sun-java5 if it is still problematic to redistribute.
Les Mikesell wrote:
Johnny Hughes wrote:
Not from Red Hat (wrt sun java) ... they did use tomcat and gcj. If you want sun java, I imagine you would have to change the specs and rebuild. I have no idea how to do that (I have not looked at it at all).
Red Hat fixed their bug: http://rhn.redhat.com/errata/RHBA-2007-0365.html
That has been pushed to updates ... however, I don't see it has any impact on open office. It is related to tomcat.
I was trying to remove the non-working tomcat with the idea of replacing it with something else and openoffice went with it. Odd, but fixable.
I haven't seen a response to centos bugzilla 0002160 that I filed a month ago about this.
I didn't see the bug before ... but it was released 7/22/2007: redhat-rpm-config-8.0.45-17.0.1.el5.centos.noarch.rpm
Thanks, but I thought the bug was related to the way the way the java-containing rpms were built (or maybe installed..) and this rpm just fixes the process. What will it take to get working indexes into the jar files for tomcat (and probably other apps) on an existing system?
The new tomcat was built with the new redhat-rpm-config, so all the System OS files should be good. AFAIK the bug you pointed to was to correct the md5sums issues for mutltiarch builds.
From the bug: brp-java-repack-jars is a post processing script included in redhat-rpm-config that removes timestamp differences in jars to ensure multi-lib packages do not conflict.
Also, is there any chance of duplicating those Red Hat sun jdk rpms? I think you've said no before, but I'm curious about how debian was able to manage it: http://packages.debian.org/unstable/source/sun-java5 if it is still problematic to redistribute.
They are not distributable by Centos ... and they are IBM Java, not Sun Java.
Debain agreed to indemnify Sun ... we won't.
Thanks, Johnny hUghes
Johnny Hughes wrote:
Les Mikesell wrote:
Johnny Hughes wrote:
Not from Red Hat (wrt sun java) ... they did use tomcat and gcj. If you want sun java, I imagine you would have to change the specs and rebuild. I have no idea how to do that (I have not looked at it at all).
Red Hat fixed their bug: http://rhn.redhat.com/errata/RHBA-2007-0365.html
That has been pushed to updates ... however, I don't see it has any impact on open office. It is related to tomcat.
I was trying to remove the non-working tomcat with the idea of replacing it with something else and openoffice went with it. Odd, but fixable.
I haven't seen a response to centos bugzilla 0002160 that I filed a month ago about this.
I didn't see the bug before ... but it was released 7/22/2007: redhat-rpm-config-8.0.45-17.0.1.el5.centos.noarch.rpm
Thanks, but I thought the bug was related to the way the way the java-containing rpms were built (or maybe installed..) and this rpm just fixes the process. What will it take to get working indexes into the jar files for tomcat (and probably other apps) on an existing system?
The new tomcat was built with the new redhat-rpm-config, so all the System OS files should be good. AFAIK the bug you pointed to was to correct the md5sums issues for mutltiarch builds.
From the bug: brp-java-repack-jars is a post processing script included in redhat-rpm-config that removes timestamp differences in jars to ensure multi-lib packages do not conflict.
Also, is there any chance of duplicating those Red Hat sun jdk rpms? I think you've said no before, but I'm curious about how debian was able to manage it: http://packages.debian.org/unstable/source/sun-java5 if it is still problematic to redistribute.
They are not distributable by Centos ... and they are IBM Java, not Sun Java.
Debain agreed to indemnify Sun ... we won't.
For the record: (f) you agree to defend and indemnify Sun and its licensors from and against any damages, costs, liabilities, settlement amounts and/or expenses (including attorneys' fees) incurred in connection with any claim, lawsuit or action by any third party that arises or results from (i) the use or distribution of your Operating System, or any part thereof, in any manner, or (ii) your use or distribution of the Software in violation of the terms of this Agreement or applicable law. You shall not be obligated under Section 2(f)(i) if such claim would not have occurred but for a modification made to your Operating System by someone not under your direction or control, and you were in compliance with all other terms of this Agreement. If the Software README file permits certain files to be replaced or omitted from your distribution, then any such replacement(s) or omission(s) shall not be considered a breach of Section 2(a).
fixing thread hijack in subject line
On Tue, 31 Jul 2007, Les Mikesell wrote:
Red Hat fixed their bug: http://rhn.redhat.com/errata/RHBA-2007-0365.html I haven't seen a response to centos bugzilla 0002160 that I filed a month ago about this.
Did you look at a system before posting? Or just shoot from the hip?
[herrold@centos-4 ~]$ lynx -dump http://rhn.redhat.com/errata/RHBA-2007-0365.html | grep -i srpm SRPMS: SRPMS: [herrold@centos-4 ~]$
no linked SRPMS
And they have a packaged Sun Java available http://rhn.redhat.com/errata/RHEA-2007-0223.html (that's the link for rhel4 but I think there is one for 5 too).
[herrold@centos-4 ~]$ lynx -dump http://rhn.redhat.com/errata/RHEA-2007-0223.html | grep -i srpm SRPMS: [herrold@centos-4 ~]$
no linked SRPMS
... cannot prove the fix exists to me so far. Sad that Red Hat feels it has to play these games.
but I see in my mirroring:
/mnt/nfs/var/ftp/pub/mirror/redhat/rhel/rhel-5/5Server/all/SRPMS/redhat-rpm-config-8.0.45-17.el5.src.rpm
dunno when it showed up and it is not worth checking my detail logs, because:
Johnny notes it has been updated and is in updates which have been issued over a week ago -- it is a convenience fix, and not a security matter
has been updated and is in updates:
version: redhat-rpm-config-8.0.45-17.0.1.el5.centos.noarch.rpm
released 7/22/2007
and _looking_, yum shows it updated on myC5 system
Les ... you have an open bug -- you think it is fixed upstream. No SRPMS are noted in teh fix release which you seemingly were able to find. The tests I did, you can do.
Why not lend a hand and point to available source RPMs rather than carp on the mailing list on stale matters?
If you dislike non-security related updates notifications, write a tool to provide you information on the changes.
-- Russ Herrold
R P Herrold wrote:
Red Hat fixed their bug: http://rhn.redhat.com/errata/RHBA-2007-0365.html I haven't seen a response to centos bugzilla 0002160 that I filed a month ago about this.
Did you look at a system before posting? Or just shoot from the hip?
No, I installed Sun java on a Centos 5 box, noticed that tomcat didn't start, googled for the error message about the missing index and found that it was a known problem.
[herrold@centos-4 ~]$ lynx -dump http://rhn.redhat.com/errata/RHBA-2007-0365.html | grep -i srpm SRPMS: SRPMS: [herrold@centos-4 ~]$
Don't you need an up2date subscription to get that stuff?
And they have a packaged Sun Java available http://rhn.redhat.com/errata/RHEA-2007-0223.html (that's the link for rhel4 but I think there is one for 5 too).
[herrold@centos-4 ~]$ lynx -dump http://rhn.redhat.com/errata/RHEA-2007-0223.html | grep -i srpm SRPMS: [herrold@centos-4 ~]$
no linked SRPMS
And that.
... cannot prove the fix exists to me so far. Sad that Red Hat feels it has to play these games.
If they didn't, we wouldn't need CentOS...
Johnny notes it has been updated and is in updates which have been issued over a week ago -- it is a convenience fix, and not a security matter
Yes, tomcat is very secure when it won't run at all. And yes it would be more convenient if it worked.
Les ... you have an open bug -- you think it is fixed upstream. No SRPMS are noted in teh fix release which you seemingly were able to find. The tests I did, you can do.
I don't have the up2date subscription.
Why not lend a hand and point to available source RPMs rather than carp on the mailing list on stale matters?
If you dislike non-security related updates notifications, write a tool to provide you information on the changes.
If google doesn't know, nothing I write is going to find it. This is what I found https://www.zarb.org/pipermail/jpackage-discuss/2007-June/011548.html and there have been several other threads on the jpackage list about similar issues in rpms built on FC6 and RHEL5.
But while we are sort-of on this topic, can someone explain the jpp in the rpm package names? Some of the posters on the jpackage list seem to have been confused about the source of their packages. Does jpp mean something unrelated to the jpackage repo?
It seems bizarre for an office suite to depend on a java servlet engine, but OK...
Now how do I get one that works under Sun java? And is there
a way to get eclipse without gcj?
Not from Red Hat (wrt sun java) ... they did use tomcat and gcj. If you want sun java, I imagine you would have to change the specs and rebuild. I have no idea how to do that (I have not looked at it at all).
http://wiki.centos.org/HowTos/JavaOnCentOS
You COULD get the OOo2 suite from the openoffice.org website ... that gets rid of the tomcat issues.
Eclipse ... not sure.
I kept having serious issues with gcj and so went to sun's version then just got a .tar.gz package from eclipse.org
I run it with: -vm /usr/lib/jvm/java-1.5.0-sun-1.5.0.12/jre/bin/java -vmargs -XX:PermSize=1024M
[-vm is because I do have gcj installed but do _not_ want to use it; -XX is that with sun's java and what I was doing, it would crash unless the vm had a larger permSize]
Shawn wrote:
It seems bizarre for an office suite to depend on a java servlet engine, but OK...
Now how do I get one that works under Sun java? And is there
a way to get eclipse without gcj?
Not from Red Hat (wrt sun java) ... they did use tomcat and gcj. If you want sun java, I imagine you would have to change the specs and rebuild. I have no idea how to do that (I have not looked at it at all).
http://wiki.centos.org/HowTos/JavaOnCentOS
You COULD get the OOo2 suite from the openoffice.org website ... that gets rid of the tomcat issues.
Eclipse ... not sure.
I kept having serious issues with gcj and so went to sun's version then just got a .tar.gz package from eclipse.org
But that's kind of horrible because now you have to keep it updated yourself.
I run it with: -vm /usr/lib/jvm/java-1.5.0-sun-1.5.0.12/jre/bin/java -vmargs -XX:PermSize=1024M
[-vm is because I do have gcj installed but do _not_ want to use it; -XX is that with sun's java and what I was doing, it would crash unless the vm had a larger permSize]
Doesn't the alternatives mechanism take care of that? It doesn't seem that well thought out, though. What if you want to run some programs under one java version and others with a different one? We're trying to update some systems currently running under centos 3.x/java 1.4.x to the most current versions that will work so I'd like to install the 1.4, 1.5, and 1.6 versions side-by-side on the same development machine so if we run into any problems we can easily test under earlier versions to see if there are differences.
On Mon, 30 Jul 2007, Les Mikesell wrote:
On CentOS 5, why does 'yum remove tomcat*' remove all of the openoffice packages?
This is a known issue in that using yum to remove packages is to use a blunt tool -- use rpm for finer control on package removals
This question ocurs often in the yum and fedora mailing lists -- see them for details
-- Russ Herrold
Hi,
This is a known issue in that using yum to remove packages is to use a blunt tool -- use rpm for finer control on package removals
It doesn't work. Taking out the tomcat5-jsp-2.0-api-5.5 keeps pulling out packages until openoffice goes too.
tomcat5-jsp-2.0-api is needed by (installed) bsf-2.3.0-11jpp.1.x86_64 bsf is needed by (installed) bsh-1.3.0-9jpp.1.x86_64 bsh is needed by (installed) openoffice.org-core-2.0.4-5.4.17.2.x86_64
Shawn
-
Johnny Hughes -
Les Mikesell -
R P Herrold -
Shawn