Обработка обновления yum с pkg-x.y.rpm, который требует mod_python до pkg-x. (Y + z) .rpm с конфликтами mod_python

С yum / rpm на RHEL 5 можно yum upgrade заставить удалить другой конфликтующий пакет - аналогично поведению apt-get dist-upgrade на Debian?

Я обновляю .spec для скорости вращения нашего продукта. Версия 4.2.x использовала mod_python, поэтому спецификация содержала

Requires: mod_python

версия 4.3.x использует mod_wsgi в режиме демона, и поэтому несовместимо с одновременной загрузкой mod_python (как упаковано в RHEL 5.x). Чтобы убедиться, что mod_python не загружен в версии 4.3.x, мы попытались использовать

Conflicts: mod_python

Я надеялся, что это позволит yum понять, что он может удалить mod_python во время обновления, но он отказывается, и я не могу найти способ настроить / проинструктировать yum в противном случае

[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

На данный момент я использую

yum remove define; yum remove mod_python; yum install define

как обходной путь. Есть ли лучший способ справиться с этим (обновление foo вызывает удаление бара) с помощью yum / rpm? Или ответ «это то, что вы не должны делать в RHEL, так что не делайте этого»?