Bug 119111

Summary: Conflicts when installing packages that include directories shared with other packages
Product: Red Hat Enterprise Linux 3 Reporter: Mike MacCana <mmaccana>
Component: up2dateAssignee: Clifford Perry <cperry>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0CC: dag, jbj, jbj, pmatilai
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-06-20 16:10:01 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 130798    
Attachments:
Description Flags
Ugly workaround patch none

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.