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:
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
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.
/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
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
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 firstname.lastname@example.org'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.