Red Hat Bugzilla – Bug 202338
udapl conflicts with dapl
Last modified: 2012-06-20 12:16:05 EDT
When running up2date to download updates, I get the following error: [snip] Testing package set / solving RPM inter-dependencies... ######################################## RPM package conflict error. The message was: Test install failed because of package conflicts: file /etc/dat.conf conflicts between attempted installs of dapl-1.2.0-1 and udapl-1.2-0.4265.2.EL4 I assume that udapl replaces dapl? (udapl is listed as a component in the Bugzilla form, but dapl isn't.) Neither of these packages is installed. Command used: /usr/sbin/up2date --download --installall=rhel-i386-es-4 --nox
Actually, dapl replaces udapl. The udapl package was part of the RHEL4 U3 tech preview of Infiniband support. The dapl package (the name was changed upstream so we followed suit) includes the line: Obsoletes: udapl <= 1.2 in the spec file and as a result should cause the udapl file to be uninstalled whenever dapl is installed. This may actually be a bug in up2date, not udapl, as the package update process should detect the Obsoletes: line and go through with the transaction. RPM succesfully handles this condition. I'm changing the component to up2date as I don't think this is actually an RPM or dapl or udapl bug. BTW, that implies that if you just downloaded the files using up2date and then ran an rpm -Uvh * on the files, it would likely work around this issue for you.
Thanks for the fast response, Doug. I'd normally do what you suggest (up2date followed by rpm), but up2date stops as soon as it detects the conflict and doesn't download any of the pending updates. I also tried running "rm /var/spool/up2date/*dapl*" to remove any existing dapl/udapl files, but that didn't resolve the conflict.
Please don't change the component, the bug isn't in udapl or dapl. The bug is in up2date. Also, removing files won't help. Up2date is detecting the conflict not because of RPM packages in /var/spool/up2date or based on files actually on the filesystem, but based upon the record of already installed files contained in the rpm file database. The only way to remove that conflict is to do something that effects that database (aka, some sort of rpm command is needed). There are two ways that you can work around the problem for now. Like I said in my first comment, rpm doesn't have this bug, so if you just download the files instead of having up2date try to install them, it will solve the issue. I noticed you said that it always fails with a conflict when you try this. You are specifying the installall= option to up2date, that overrides the download option and forces up2date to perform certain checks. A better method would be: rm -f /var/spool/up2date/* up2date --nox --download --channel=rhel-i386-es-4 rpm -Uvh /var/spool/up2date/* That would work around the problem by using RPM's conflict solver when installing packages instead of up2date's conflict solver. Another way to work around the problem would be to do: rpm -e udapl udapl-devel udapl-debuginfo (if the command fails because some aren't installed, remove the ones that aren't installed and do over). This just avoids the conflict entirely by removing the udapl package before attempting to run up2date. Once udapl is no longer installed, up2date should not detect any conflicts and things should work fine. But, like I said in my last comment, the fact that udapl and dapl are conflicting is a bug in up2date, not a bug in udapl. The spec file for dapl is written to avoid this conflict, up2date is not honoring it.
"up2date --nox --download --channel=rhel-i386-es-4" fails with the error: Please specify either -l, -u, --register, --configure, --installall=<channel label>, or package names as command line arguments. I got the desired result by explicitly excluding udapl and udapl-devel: up2date --nox --download --installall=rhel-i386-es-4 --exclude=udapl --exclude=udapl-devel
My suspicion is that the udapl packages are still present in the RHN channel and weren't removed as I had intended for them to be. I've notified the release engineering department of this bug and the issue. Since you have a work around, this is obviously a low priority, but at a minimum, we should be able to make sure it doesn't happen again for the next update.
User bnackash@redhat.com's account has been closed
Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. The release for which you requested us to review is now End of Life. Please See https://access.redhat.com/support/policy/updates/errata/ If you would like Red Hat to re-consider your feature request for an active release, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.