Bug 119111 - Conflicts when installing packages that include directories shared with other packages
Summary: Conflicts when installing packages that include directories shared with other...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: up2date
Version: 3.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Clifford Perry
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: 130798
TreeView+ depends on / blocked
 
Reported: 2004-03-25 05:26 UTC by Mike MacCana
Modified: 2012-06-20 16:10 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-06-20 16:10:01 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Ugly workaround patch (724 bytes, patch)
2004-04-13 05:02 UTC, Panu Matilainen
no flags Details | Diff

Description Mike MacCana 2004-03-25 05:26:47 UTC
Description of problem:
I've been told that it's comon practice for directories to be owned by
multiple packages. For example:

rpm -qf /usr/X11R6/lib
filesystem-2.2.1-3
XFree86-libs-data-4.3.0-55.EL

Up2date conflicts when installing packages that include directories
shared with other packages, even when rpm -i and rpm -U don't.

Eg:

Test install failed because of package conflicts:
file /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi from
install of perl-Digest-SHA1-2.07-1.rhel3.dag conflicts with file from
package perl-Net-DNS-0.38-0.dag.rhel3

File from installed package:
ls -ld /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi
drwxr-xr-x   14 root     root         4096 Oct 26 22:40
/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi

File from new package that apparently conflicts (after using --root to
install relative to /tmp):
ls -ld /tmp/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi  
                                                                     
                 
drwxr-xr-x    4 root     root         1024 Mar 25 16:15
/tmp/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi

Using rpm -U or rpm -i to install the package works fine.

Version-Release number of selected component (if applicable):
up2date-4.3.11-2.1.1

How reproducible:
Always

Steps to Reproduce:
1.Attempt to install a package off an apt type repository that
includes directories shared with other packages. 

 
Actual results:
The update will fail, warning about conflicts.


Expected results:
The package should install with up2date, just as it would when using
the rpm command.

Additional info:

Comment 1 Seth Vidal 2004-03-25 05:30:31 UTC
just following this b/c I think yum might be affected too.

Comment 2 Adrian Likins 2004-03-30 23:21:22 UTC
cc'ing jbj

Comment 3 Panu Matilainen 2004-04-06 06:57:52 UTC
I'd guess this has to do with the fact that apt's genpkglist strips
out file sizes, file/dir ownerships and permissions etc out of the
pkglists, making shared directories seem like they'd conflict because
of different attributes.
Easily worked around by adding rpm.RPMPROB_FILTER_REPLACEOLDFILES in
the simulated ts run but sure it's ugly. 

Oh and btw RPMTAG_OS is included in the pkglists by any recent apt,
depends of course how backwards compatible you want to be.

Comment 4 Mike MacCana 2004-04-13 01:25:47 UTC
Panu: could you provide more information on your workaround? 

Comment 5 Panu Matilainen 2004-04-13 05:02:46 UTC
Created attachment 99351 [details]
Ugly workaround patch

This works around the problem by ignoring the conflicts during the
test-transaction, real conflicts would still abort the run during the actual
transaction so it's not *that* bad. Ugly nevertheless... Patch against 4.3.10
but should apply to 4.2.x as well.

Comment 6 Dag Wieers 2004-08-07 23:45:21 UTC
Any updates on this yet ? I noticed the latest up2date update for
RHEL3 didn't have it fixed. It's quite annoying and I have had many RH
EL3 users that experienced this problem.

Comment 7 Dag Wieers 2004-08-30 02:29:27 UTC
Seems the same bug to me as: 

    https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=106123

Comment 8 Dag Wieers 2005-01-05 20:12:49 UTC
Now that U4 is out, can we have this fixed by U5 ?

Apt itself is not bailing out, neither is yum.

Comment 9 Dag Wieers 2005-01-05 20:22:14 UTC
Some other bug-reports concerning the same thing:

    bug #106123
    bug #126922
    bug #130556

and

    http://bugzilla.fedora.us/show_bug.cgi?id=2306

I'm not able to mark them as duplicates though.

Comment 10 Dag Wieers 2005-02-21 00:17:33 UTC
Still not solved with RHEL4:

Testing package set / solving RPM inter-dependencies...
########################################
RPM package conflict error.  The message was:
Test install failed because of package conflicts:
file /usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi/Net from
install of perl-Net-SSLeay-1.25-1.2.el4.rf conflicts with file from
package perl-Net-DNS-0.48-1.2.el4.rf
file /usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi/auto/Net
from install of perl-Net-SSLeay-1.25-1.2.el4.rf conflicts with file
from package perl-Net-DNS-0.48-1.2.el4.rf
file /etc/squid conflicts between attempted installs of
squidguard-1.2.0-2.2.el4.rf and squid-2.5.STABLE6-3.4E.3
file /usr/lib/perl5/vendor_perl/5.8.5/IO from install of
perl-IO-Socket-SSL-0.96-1.2.el4.rf conflicts with file from package
perl-IO-Multiplex-1.08-2.2.el4.rf
file /usr/lib/perl5/vendor_perl/5.8.5/Mail conflicts between attempted
installs of perl-MailTools-1.66-1.2.el4.rf and spamassassin-3.0.1-0.EL4
file /usr/lib/perl5/vendor_perl/5.8.5/IO from install of
perl-IO-stringy-2.109-1.2.el4.rf conflicts with file from package
perl-IO-Multiplex-1.08-2.2.el4.rf

And a major PITA.

Comment 11 Adrian Likins 2005-03-14 22:14:09 UTC
committed panu's patch to cvs, couldn't really think of any
other way to address this, and that seems acceptable.

4.4.12 should have the fix

Comment 12 Jiri Pallich 2012-06-20 16:10:01 UTC
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.