Bug 209306

As you're probably aware this is also being discussed on f-d-l I'm copy and
pasting some usefull comments here for tracking:

Rex Dieter wrote:
> Ralf Ertzinger wrote:
>  
>> On Wed, 4 Oct 2006 11:07:23 -0400, Jesse Keating wrote:
>>
>>> I do believe this should have been a --justdb flag.
>> Still, if there is still a package owning these files installed
>> after the removal the files ought to stay.
> 

Exactly, this used to work fine with previous versions (FC-5) of rpm, actually
you do not want to use --justdb, because if files were removed / renamed fomr
one version-release to the other you would ned up with stale unowned files.

I'm using rawhide for a long time and as such often have yum breakage causing
this kinda dual version installs and have been using rpm -e old-version without
--justdb hapily to fix this for a long time.

Also as reported earlier the same thing happens when removing one arch of a
multi-arch package.

The patch for removing skipDirs was deliberately removed as it caused huge
performance degredation.  See bug #187308.  Revisiting the fingerprinting code
is not something that will happen for FC6.

I must say that doesn't seem a good trade off, if I've read bug #187308
correctly, then their wasn't a real problem as the guys DIMM's where bad. So the
patch got dropped because if someone decides to install many kernels rpm starts
using a lot of memory.

So we can choise between:
1) Using lots of memory if someone has many kernels installed
   (unlikely with our current yum setup)
2) Remove semi random files when someone decides to remove an i386 package
   of which the x86_64 version is also installed.

Hmmm, yeah really hard choice

Hint: You could pare the skipDir list back to "/lib/modules" and nothing else.

FWIW, this issue is fixed (by reverting the band-aid needed because yum was
installing kernel of the day on every bleeping user machine) in rpm-4.4.7 
(since 4/1/2006).

I agree with Hans. This has bitten me a few times.

The "semi-random" files is exactly deterministic, identical to
files on the paths mentioned in the skipDirs list:
    _skip("/usr/share/zoneinfo"),
    _skip("/usr/share/locale"),
    _skip("/usr/share/i18n"),
    _skip("/usr/share/doc"),
    _skip("/usr/lib/locale"),
    _skip("/usr/src"),
    _skip("/lib/modules"),

And its noyt exactly like this is a new behavior. In fact, it is *exactly*
the behavior ordered by the RH devel team when I did the implementation.

All issues were pointed out *by me* at that time. "I'm shocked, simply shocked!" exclamations
and discussion days before FC6 final are ingenuous.

I've done some more testing and I'm starting to understand now. Can we please
take /usr/share/doc and /usr/share/locale out of this list, with the current
setup I get missing docs and worse missing translations when removing i386
versions of double installed packages.

(aside) The alternative is to identify multiply owned files on those paths
and decide a single package as owner for shared files.

No matter what, the skipDirs band-aid needs to be eliminated from rpm.

(In reply to comment #8)
> (aside) The alternative is to identify multiply owned files on those paths
> and decide a single package as owner for shared files.
> 

That won't work mith a multi-arch setup where both the i386 and x86_64 rpm's
will own the commmon files, this is the scenario that has me worried. I still
think that removing /usr/share/doc and /usr/share/locale from the skipdirs list
is a good fix for now and soon be done ASAP preferably before FC-6, it seems
like a quick and safe fix to me.

Yes, infeasible (but would "work").

If up to me, I'd remove skipDirs entirely. In fact, that was done on 4/1/2006.

I agree with comment #3, I think there really ought to be an RPM update 
reverting the #187308 fix ASAP, as that was likely not even a real bug, whereas 
this regression is definitely real.

By the way, this not only affects x86_64 multilibs, but also removal of 
duplicates after a failed transaction.

Created attachment 144573 [details]
Trivial patch reverting #187308 fix

I have attached a trivial specfile patch which should fix this problem for
those who want to try it. (I'm not uploading SRPMs or RPMs because I don't have
a good place to upload them to.)

WARNING: This patch is NOT endorsed by the Fedora Project or Red Hat, it is
only provided in the hope that it will be useful. I doubt this patch will break
RPM as it was effectively in force up to FC5, but if it does break, don't blame
me. You have been warned.

I feel that the problem is that RPM does not model sharing between packages that
are the same except for architecture.  Another symptom is reported in
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=128622

I feel that computers were intended to have only a single architecture, just like paths
can contain one and only one type of contents. Int rela, non-virtual world, its perfectly obvious
that 2 objects cannot occupy the same space-time point, quantum mechanics be damned.

All depends on the definition of "same". If truly the "same", why do you need two packages?

This was originally reported as bug 119372, later marked as dup of bug 140055
(see also bug 140055 comment #13).

FWIW, this problem has been solved in rpm-4.4.6 and later (almost a year now, 4/1/2006)
by removing deliberately introduced breakage.

Marking DUPES is rearranging deck chairs on the Titanic, the cause is well known ...

Jeff, this is a Red Hat bugzilla, tracking bugs in Red Hat and Fedora packages.

Go be crazy somewhere else, ok?

Then *fix* the bleeping problem.

One potential answer to the problem is "Don't have conflicting files then".
That's the gist of bug 235757.

Although that answer is more viable for binaries than documentation, perhaps.

*** Bug 243224 has been marked as a duplicate of this bug. ***

Panu, any chance you can do something about this?

Oh, I see Panu is already on it, see this 1-week-old thread:
https://lists.dulug.duke.edu/pipermail/rpm-maint/2007-June/000379.html
That's good news.

CLOSED

No, this is NOT closed until this is fixed in Fedora, i.e. either this is fixed 
in the rpm.org tree and Fedora updates to a new version with the fix or this is 
fixed in a Fedora patch.

The rpm5.org tree is entirely irrelevant.

Oh, it has been fixed upstream for 4.4.2.1 on June 19:
http://hg.rpm.org/rpm?cs=c9fb2eb5ae26

Let's hope 4.4.2.1 gets released and into Fedora soon.

Fixed in next rawhide push by rpm 4.4.2.1-rc1