Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

With yum/rpm on RHEL 5 can a yum upgrade be made to remove another, conflicting package - similar to the behaviour of apt-get dist-upgrade on Debian?

I am updating the .spec for our product's rpm. Version 4.2.x used mod_python, so the spec contained

Requires: mod_python

version 4.3.x uses mod_wsgi in daemon mode, and thus is incompatible with having mod_python loaded simultaneously (as packaged in RHEL 5.x). To make sure mod_python is not loaded in version 4.3.x we've tried to use

Conflicts: mod_python

I was hoping that this would allow yum to realise it could remove mod_python at the time of upgrade, but it refuses and I cannot find a way to configure/instruct yum otherwise

[root@server ~]# yum upgrade define
Loaded plugins: downloadonly, rhnplugin, security
Skipping security plugin, no data
Setting up Upgrade Process
Resolving Dependencies
Skipping security plugin, no data
--> Running transaction check
---> Package define.x86_64 0:4.3.14-1 set to be updated
--> Processing Dependency: shibboleth for package: define
--> Running transaction check
---> Package shibboleth.x86_64 0:2.4.3-2.2.el5 set to be updated
--> Processing Dependency: opensaml-schemas for package: shibboleth
--> Processing Dependency: xmltooling-schemas for package: shibboleth
--> Processing Dependency: libxmltooling-lite.so.5()(64bit) for package: shibboleth
--> Processing Dependency: libxerces-c-3.1.so()(64bit) for package: shibboleth
--> Processing Dependency: libsaml.so.7()(64bit) for package: shibboleth
--> Processing Dependency: liblog4shib.so.1()(64bit) for package: shibboleth
--> Processing Dependency: libodbc.so.1()(64bit) for package: shibboleth
--> Processing Dependency: libxml-security-c.so.16()(64bit) for package: shibboleth
--> Processing Dependency: libxmltooling.so.5()(64bit) for package: shibboleth
--> Running transaction check
---> Package libsaml7.x86_64 0:2.4.3-3.2.el5 set to be updated
---> Package libxerces-c-3_1.x86_64 0:3.1.1-2.2.el5 set to be updated
---> Package libxml-security-c16.x86_64 0:1.6.1-3.1.el5 set to be updated
---> Package libxmltooling5.x86_64 0:1.4.2-2.1.el5 set to be updated
---> Package log4shib.x86_64 0:1.0.3-2.1 set to be updated
---> Package opensaml-schemas.x86_64 0:2.4.3-3.2.el5 set to be updated
---> Package unixODBC-libs.x86_64 0:2.2.11-10.el5 set to be updated
---> Package xmltooling-schemas.x86_64 0:1.4.2-2.1.el5 set to be updated
--> Processing Conflict: define conflicts mod_python
--> Finished Dependency Resolution
define-4.3.14-1.x86_64 from define-development has depsolving problems
  --> define conflicts with mod_python
Error: define conflicts with mod_python
 You could try using --skip-broken to work around the problem
 You could try running: package-cleanup --problems
                        package-cleanup --dupes
                        rpm -Va --nofiles --nodigest

At the moment I'm using

yum remove define; yum remove mod_python; yum install define

as a workaround. Is there a better way to handle this (upgrade foo triggers removal of bar) with yum/rpm? Or is the answer "this is something you aren't meant to do on RHEL, so don't do it"?

share|improve this question
add comment

1 Answer

up vote 0 down vote accepted

I don't think yum can do this; the only way out of a conflict is to prep the system to avoid it. It's possible a plugin could modify yum's behaviour and propose package removal to resolve the conflict, but I'm not aware of one.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.