Bug 202338 - udapl conflicts with dapl
udapl conflicts with dapl
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: up2date (Show other bugs)
4.3
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Pradeep Kilambi
Ken Reilly
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-08-12 21:22 EDT by taylpm
Modified: 2012-06-20 12:16 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-06-20 12:16:05 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description taylpm 2006-08-12 21:22:27 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
Comment 1 Doug Ledford 2006-08-12 23:19:41 EDT
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.
Comment 2 taylpm 2006-08-13 00:43:50 EDT
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.
Comment 3 Doug Ledford 2006-08-13 11:06:43 EDT
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.
Comment 4 taylpm 2006-08-13 21:05:46 EDT
"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
Comment 5 Doug Ledford 2006-08-24 20:12:32 EDT
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.
Comment 6 Red Hat Bugzilla 2007-04-11 21:04:58 EDT
User bnackash@redhat.com's account has been closed
Comment 8 Jiri Pallich 2012-06-20 12:16:05 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.