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
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 freshrpms
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 run.
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 #130556.
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.