Bug 106123 - up2date from apt repositories fails with "file" conflict on directories.
up2date from apt repositories fails with "file" conflict on directories.
Product: Fedora
Classification: Fedora
Component: up2date (Show other bugs)
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Bret McMillan
Fanny Augustin
: 152858 (view as bug list)
Depends On:
Blocks: 120092
  Show dependency treegraph
Reported: 2003-10-02 18:47 EDT by Paul Nasrat
Modified: 2007-11-30 17:10 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-10-29 08:43:49 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Paul Nasrat 2003-10-02 18:47:56 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703

Description of problem:
Using Arjan's p.r.c repo using apt fails as follows:

Testing package set / solving RPM inter-dependencies...
RPM package conflict error.  The message was:
Test install failed because of package conflicts:
file /lib/modules from install of kernel-2.6.0-0.test6.1.47 conflicts with file
from package filesystem-2.2.1-4

/lib/modules is marked as %dir and up2date should not find a dir as a conflict
it is already owned by multiple packages including 2.4 kernels installed by
up2date.  Only difference is this is an apt repo rather than rhn.

Wiping the headers/rpm cache (rm -f /var/spool/up2date/kernel-2.6*) and
switching to using same repo as a yum repository then works successfully, as
does up2date --get then rpm -ivh.

The failure occurs in depSolver.py in the run method of DependencySolver class.

Version-Release number of selected component (if applicable):
up2date 3.9.29-2

How reproducible:
Always if don't change config

Steps to Reproduce:
1. add to /etc/sysconfig/rhn/sources apt arjan-2.6-kernel-i386
http://people.redhat.com ~arjanv/2.5/ kernel
2.  up2date -f kernel


Actual Results:  Fails with error message

Expected Results:  Successfull install

Additional info:

Work around - use yum repo functionality in up2date rather than apt
Comment 1 Paul Nasrat 2003-10-03 03:10:36 EDT
Curious side affect I noticed whilst testing

1) have apt repo set up.
2) Remove hdr/rpm files from an rpm only in that repo
3) Switch to yum version of same repo - handles fine
4) Remove hdr/rpm files from same rpm
5) Switch back to apt repo
6) up2date now hangs in a loop trying to stat the .hdr and rpm files.
Comment 2 Hans de Goede 2003-11-17 07:46:32 EST
I can confirm this one, it also happens when trying to install other
rpms through apt with up2date. I tried using the fedora.us apt
repositories because I was sick of yums download all headers al the
time  feature, but with apt I hit the dirs conflict bug.
Comment 3 Aleksey Nogin 2003-12-04 17:51:31 EST
I am seing the same problem with

apt fedora-1 http://ayo.freshrpms.net fedora/linux/1/i386 os updates
Comment 4 Panu Matilainen 2004-01-26 06:38:38 EST
I think this happens because apt pkglists don't include directory
mode, user + group information in them -> the directory to be
installed looks different than the one in the system already causing
conflict, similarly to older apt's omitting the OS header in the
pkglists (see comment in depSolve.py at around line 725).

There's no nice fix for this I'm afraid, can be worked around by
adding rpm.RPMPROB_FILTER_REPLACEOLDFILES to the  probFilter but
that's .. icky to say the least. The other option is to add the
necessary additional fields to apt pkglists but that doesn't help the
situation with repositories generated by older versions.
Comment 5 Panu Matilainen 2004-01-26 06:41:18 EST
Hum, of course the REPLACEOLDFILES isn't *that* bad since it only
needs to be used during the transaction test-run, not on the real ts run.
Comment 6 Hans de Goede 2004-01-26 09:04:22 EST
Since up2date UPDATES existing packages why not just check the old
version for information on directories, or even just check the entire
rpm database / the filesystem itself.

The only problem I can think of is when an updated package then
contains a dir which isn't yet on the system, but that should never
give a conflict right?

This should work even for installing from apt repositories, since
either its a new dir, so no conflict, or it is already there and you
can check the existing rpm db / fs to see wether it is a dir or a file.
Comment 7 Panu Matilainen 2004-01-26 09:57:49 EST
Trying to verify another version of a package based on information in
another another is completely bogus, package contents can and do
change. Might just as well not check at all.

Besides the comparison mechanism is inside rpmlib, not up2date -> you
can't really change the behavior apart from setting various flags to
make rpm ignore certain error conditions like REPLACEOLDFILES.
Comment 8 Hans de Goede 2004-01-27 03:47:51 EST
I really don't see the problem, all I propose is for apt metainfo, to
see if the file already exists and in that case if it is a dir, add
the dir flag to the metainfo before passing it to rpmlib.

What are the chances of a file already exisiting as a dir and not
being a dir in the newer package??

Comment 9 Jos Vos 2004-06-06 11:32:50 EDT
To comment on the last question: if we start talking about "chances"
that things happen, we end up in messy software that at some day will
break things. Let's not do that...

About Panu's suggestion "to add the necessary additional fields to apt
pkglists": is this doable upwards compatible and what programming
effort would it take, both on the apt side and on the up2date side?
Comment 10 Panu Matilainen 2004-06-07 03:26:27 EDT
Provided that my analysis of the problem is correct (I haven't gotten
around to test it) the fix on apt's side is trivial and wouldn't do
any harm to apt (except for increasing the size of the package indexes
with information apt itself has no use for). Haven't checked how much
the index sizes would actually increase by adding the necessary bits.

Alternatively (or in addition, to provide compatibility with
repositories created with older versions of apt) up2date might perhaps
check whether the file ownership etc information exists and if not,
enable rpm.RPMPROB_FILTER_REPLACEOLDFILES flag in the test transaction
Comment 11 William M. Quarles 2004-11-28 02:01:55 EST
Reality check guys: considering that APT checks for file conflicts and
does not complain about these directory "conflicts," I really think
that the problem is in Up2Date, not in APT.

Not to mention that I had to file a bug report (which I completely
forgot that I did) for similar conflicts when accessing an official
mirror yum repository for official Fedora Core updates (bug #126922)

Someone thinks that they have found a fix for this problem, see bug
Comment 12 William M. Quarles 2005-04-03 14:52:00 EDT
I reported this quite a while ago in Fedora Legacy, now listed as Red Hat bug
#152858.  The problem exists with yum repositories as well (as said not quite
directly in my previous post).  You need to be looking at both yum and apt
repositories and how up2date treats them when trying to fix this problem.
Comment 13 Jos Vos 2005-04-03 14:57:01 EDT
To my best knowledge (and I use up2date a lot with yum repositories) the problem
does *not* exist with yum repositories.
Comment 14 William M. Quarles 2005-04-03 15:18:31 EDT
Note my Comment #11, go to my report on the kernel-doc header problem.

Also try Planet CCRMA.

yum yum-planetccrma http://ccrma.stanford.edu/planetccrma/yum/fedora/1/planetccrma/

yum yum-planetcore http://ccrma.stanford.edu/planetccrma/yum/fedora/1/planetcore/

It came up with the same errors in Fedora Core 1; try 2 or 3 and see what
happens.  I upgraded to Fedora Core 2 a little while ago, but I've got a monster
download happening with up2date right now and I can't stop it to test.
Comment 15 Matthew Miller 2005-04-12 13:50:53 EDT
*** Bug 152858 has been marked as a duplicate of this bug. ***
Comment 16 John Thacker 2006-10-29 08:43:49 EST
Note that FC2 is no longer supported even by Fedora Legacy.  Also, up2date has
been replaced by pirut and pup since FC5.  FC3 and FC4 are supported by Fedora
Legacy for security issues only.  If this still occurs on FC3 or FC4 and is a
security issue, please reopen and assign to that version and Fedora Legacy.  If
it occurs on RHEL 3 or 4, please reassign or refile against that product.

The codebase for pirut and pup is quite different, so existing bugs do not
apply, but please continue testing them on the still supported versions of
Fedora Core and file bugs as necessary.

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