Red Hat Bugzilla – Bug 106123
up2date from apt repositories fails with "file" conflict on directories.
Last modified: 2007-11-30 17:10:31 EST
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):
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
Work around - use yum repo functionality in up2date rather than apt
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.
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.
I am seing the same problem with
apt fedora-1 http://ayo.freshrpms.net fedora/linux/1/i386 os updates
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.
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.
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.
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.
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??
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?
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
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
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.
To my best knowledge (and I use up2date a lot with yum repositories) the problem
does *not* exist with yum repositories.
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.
*** Bug 152858 has been marked as a duplicate of this bug. ***
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.