Bug 106123

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.